Core Web Vitals in plain language: LCP, INP and CLS

Measure first

PageSpeed Insights shows two kinds of results. Field data comes from real Chrome users over the last 28 days; the Core Web Vitals assessment uses it. Lab data, a single Lighthouse test on one device, helps you find causes.

Search Console’s Core Web Vitals report groups similar pages, shows mobile and desktop separately, and rates each group by its worst metric. Low-traffic pages may have no data. On Shopify, the Online Store › Themes page also shows 30 days of real-visitor data.

Anything between “good” and “poor” needs improvement:

• LCP (main content load): good at 2.5 seconds or less, poor above 4 seconds.
• INP (responsiveness): good at 200 milliseconds or less, poor above 500 milliseconds.
• CLS (layout shift): good at 0.1 or less, poor above 0.25.

1. LCP: when does the main content appear?

LCP (Largest Contentful Paint) is the time from opening the page until the largest image, text block or video on screen has rendered. That can be a hero image, a product photo or the heading.

If LCP is poor, check these:

• The server responds slowly, or visitors arrive through several redirects.
• The main image is found late: it’s set to lazy-load, or defined in a script or CSS file instead of the HTML.
• The file is far larger than its display size, or not in an efficient format such as WebP or AVIF.
• CSS and JavaScript at the top of the page hold up rendering.

Start with the main image: put it in the HTML, remove lazy loading, give it priority (fetchpriority="high") and serve it at display size in WebP or AVIF. For the server and the other usual suspects, see Why is your site slow? The 7 most common causes.

2. INP: how quickly does the page respond?

INP (Interaction to Next Paint) is the time from a click, tap or key press until the result appears on screen; scrolling and hovering don’t count. It reports the visit’s slowest interaction, minus rare outliers.

INP replaced FID (First Input Delay) on March 12, 2024; FID only measured the wait before the first interaction.

The browser’s main thread does one task at a time, so a click made during a long task (over 50 milliseconds) has to wait. Check these:

• Heavy JavaScript loading with the page, which delays taps made during loading.
• Third-party code: live chat, ad and tracking scripts.
• A very large page structure (DOM), which makes every screen update heavier.

Remove plugins and apps you don’t use, and defer code that isn’t essential. In a store, test “Add to cart”, variant pickers, filters and the menu first; for other checkout obstacles, see 8 ways to reduce cart abandonment.

Lighthouse can’t measure INP, because nobody clicks during its test; it shows Total Blocking Time (TBT) instead.

3. CLS: does the page jump while it loads?

CLS (Cumulative Layout Shift) measures unexpected movement on the page. It’s a score, not seconds: it combines how much of the screen moved and how far. Shifts within 500 milliseconds of the visitor’s own click don’t count.

You go to tap a button, the page moves, and you hit something else. The most common causes:

• Images and videos without width and height.
• Ads, embeds and iframes with no space reserved.
• Content injected late, especially near the top of the page.
• Web fonts that render larger or smaller than the fallback font.

Reserve space up front: give images and videos width and height (or a CSS aspect-ratio), fix the size of ad and embed slots, and don’t insert new content above existing content. For fonts, size-adjust and preloading narrow the gap.

4. How Google uses Core Web Vitals

Google says Core Web Vitals are used by its ranking systems, and that it always tries to show the most relevant content, even if the page experience is sub-par. Speed doesn’t replace content; it can make the difference when many similar pages compete.

The 0–100 score in PageSpeed Insights isn’t the Core Web Vitals assessment either; it summarizes a Lighthouse lab test. Google itself says chasing a perfect score just for SEO may not be the best use of your time.

A realistic goal: all three metrics good, on mobile and desktop, on the pages that matter. PageSpeed Insights only passes the assessment when all three are good. Planning a redesign? Measure before and after launch; see Keep your Google rankings through a redesign.

Where to start

As Google recommends, start with the groups marked “Poor” in Search Console, then the pages that bring the most visitors and sales: the homepage, best-sellers, ad landing pages. Field data covers 28 days, so give each fix a few weeks.

LCP, INP and CLS are the first three checks in our free 48-point inspection. Alongside them we look at server response time, image weight and plugin or app load, and rank the findings by business impact, so you know which fix to start with.