Core Web Vitals explained: LCP, INP and CLS in plain English

Core Web Vitals are three measurements Google uses to describe how a page feels to real visitors: how fast the main content appears, how quickly the page responds to a tap, and whether things jump around while it loads. They’re part of how Google assesses page experience, and more importantly, they track the things that make visitors leave.

The three metrics#

Metric	Measures	Good	Poor
LCP, Largest Contentful Paint	How long until the main content (usually the biggest image or heading) is visible	2.5 s or less	Over 4 s
INP, Interaction to Next Paint	How long the page takes to visibly respond after a click, tap or key press	200 ms or less	Over 500 ms
CLS, Cumulative Layout Shift	How much the layout jumps unexpectedly while you use the page	0.1 or less	Over 0.25

Anything between “good” and “poor” is rated needs improvement. Google judges each metric at the 75th percentile of real visits, so a page passes when at least three out of four visits have a good experience.

INP replaced an older metric, First Input Delay (FID), in March 2024. If you read advice about FID, it’s out of date.

Lab data and field data#

There are two kinds of measurement, and they often disagree:

• Field data comes from real Chrome users visiting your site over the last 28 days. This is what Google uses. You’ll find it at the top of PageSpeed Insights and in Search Console’s Core Web Vitals report, once a site has enough traffic.
• Lab data is one test run on a simulated device, like the Lighthouse score. It’s useful for finding causes and testing fixes, but the score itself isn’t what Google ranks on.

So a Lighthouse score of 70 with good field data is fine, and a score of 100 doesn’t guarantee good field data on slow phones.

Common causes and fixes#

Slow LCP#

• A huge hero image. Resize it to the size it’s shown at and use a modern format like WebP or AVIF.
• The main image loads late. Don’t lazy-load the image at the top of the page, and consider fetchpriority="high" on it.
• A slow server or no caching. Static pages from a CDN load fastest.
• Render-blocking files, such as large CSS files or fonts loaded before anything can be shown.

Slow INP#

• Too much JavaScript on the main thread. Third-party scripts like chat widgets, trackers and ad tags are the usual cause. Remove what you don’t use; load the rest later.
• Heavy work in click handlers. Show feedback immediately, then do the slow part. In JavaScript, breaking long tasks into smaller pieces lets the browser respond in between.
• Large pages that re-render on every interaction, common in React apps. See useMemo and useCallback and, before that, the profiler.

High CLS#

• Images and videos without dimensions. Always set width and height (or a CSS aspect-ratio) so the browser reserves the space.
• Banners and embeds inserted above content after load, such as cookie notices or ads. Reserve their space, or show them as overlays.
• Web fonts swapping in with different sizes. Choosing fallback fonts with similar proportions reduces the jump.

On Wix#

Wix handles hosting, the CDN and image formats for you, so most Wix speed problems come from what’s on the page: too many apps and embeds, heavy animations, large videos at the top, and custom code that runs on load. Why your Wix site is slow goes through the fixes, and Wix’s Site Speed dashboard shows its own Core Web Vitals data.

How much do they matter for SEO?#

Core Web Vitals are one signal among many. A page with the best answer to a search will usually outrank a faster page with a worse one. But when pages are similarly relevant, experience can make the difference, and a slow or jumpy page loses visitors whatever its ranking. Treat them as a user-experience target that also helps search, not as a trick.

To check the rest of a site’s SEO basics, see the Wix SEO checklist and structured data explained.

If you want a fast, search-ready Wix site, I do Wix website design.