Skip to content
Super Site Report logo Super Site Report Website health checker
Site Speed

Core Web Vitals Explained: LCP, INP and CLS Thresholds and Fixes

By SuperSiteReport Team · Updated · 7 min read

Core Web Vitals are Google’s three metrics for real-world page experience: Largest Contentful Paint (loading, good at 2.5 seconds or less), Interaction to Next Paint (responsiveness, good at 200 milliseconds or less) and Cumulative Layout Shift (visual stability, good at 0.1 or less). A page passes when at least 75% of visits meet all three.

Core Web Vitals turn “this site feels slow” into numbers you can measure and fix. They are part of Google’s page experience guidance, they appear in Search Console and PageSpeed Insights, and they line up closely with what frustrates visitors: a blank screen, a button that does nothing when tapped, or text that jumps just as you try to read it. This guide explains each metric, its thresholds, what usually causes a bad score, and how to fix it. You can see your own lab numbers in a free Super Site Report scan, which runs a mobile Lighthouse test on every site.

What are the three Core Web Vitals?

Metric What it measures Good Needs improvement Poor
Largest Contentful Paint (LCP) How long until the largest image or text block in the viewport is shown ≤ 2.5 s 2.5–4 s > 4 s
Interaction to Next Paint (INP) How quickly the page visibly responds to clicks, taps and key presses, across the whole visit ≤ 200 ms 200–500 ms > 500 ms
Cumulative Layout Shift (CLS) How much visible content moves unexpectedly while the page is in use ≤ 0.1 0.1–0.25 > 0.25

Google recommends measuring at the 75th percentile of page loads, separately for mobile and desktop. In practice, three out of four visits need to be “good” for the page to pass. The reasoning behind these thresholds is documented on web.dev in Defining the Core Web Vitals metrics thresholds.

What happened to First Input Delay?

First Input Delay (FID) measured only the delay before the first interaction was handled. Interaction to Next Paint replaced it as a Core Web Vital on 12 March 2024, as announced on web.dev. INP is stricter: it looks at nearly every interaction during the visit and includes the time to process the event and paint the result, not only the initial delay. Sites that passed FID easily can fail INP, especially on mid-range phones running heavy JavaScript.

What is Largest Contentful Paint and how do you improve it?

Largest Contentful Paint is the time from when the user starts loading the page to when the largest visible element, usually a hero image, banner or headline, finishes rendering. web.dev’s Optimize LCP guide breaks it into four parts: server response time, resource load delay, resource load duration and element render delay. Fix whichever part is largest.

  • Slow server response. Use page caching, a CDN, and a host close to your visitors. Time to first byte should be well under a second; see web.dev’s TTFB guide.
  • Late discovery of the LCP image. Put it in the HTML as a normal <img> rather than a CSS background or a JavaScript slider, and add fetchpriority="high".
  • Lazy-loading the hero. loading="lazy" is for images below the fold. Lazy-loading the main image above the fold delays LCP.
  • Heavy images. Serve responsive sizes with srcset and modern formats such as WebP or AVIF. The web.dev Learn Images course covers the details.
  • Render-blocking CSS and fonts. Inline critical CSS, defer the rest, and use font-display: swap.

What is Interaction to Next Paint and how do you improve it?

Interaction to Next Paint records how long the page takes to show a visual response after each click, tap or key press. The reported value is close to the slowest interaction of the visit (very long visits ignore a few outliers). Poor INP almost always means the browser’s main thread is busy running JavaScript when the user tries to interact. The Optimize INP guide lists the techniques; the most effective are:

  • Ship less JavaScript. Remove unused plugins, widgets and tracking tags. Every third-party script competes for the main thread.
  • Break up long tasks. Split work into smaller chunks and yield to the browser so it can respond to input between them.
  • Keep event handlers light. Show visual feedback first, then do expensive work afterwards.
  • Avoid huge DOMs. Very large pages make every style and layout update slower.

Lighthouse cannot measure INP because it does not interact with the page. It reports Total Blocking Time (TBT) instead, which measures main-thread blocking during load and is a useful lab proxy. If TBT is high in your Super Site Report, INP is likely to be a problem for real users.

What is Cumulative Layout Shift and how do you improve it?

Cumulative Layout Shift scores how much visible content moves without the user causing it. Each shift is scored by how much of the viewport moved and how far, and CLS reports the largest burst of shifts during the visit. web.dev’s Optimize CLS guide covers the common causes:

  • Images and videos without dimensions. Always set width and height attributes (or CSS aspect-ratio) so the browser reserves space.
  • Ads, embeds and banners injected late. Reserve space with a fixed-height container, and never insert content above what the user is reading.
  • Web fonts swapping in. Preload key fonts and pick fallback fonts with similar metrics.
  • Animations that change layout. Animate transform and opacity instead of top, height or margin.

What is the difference between lab data and field data?

Lab data Field data
Source A controlled test such as Lighthouse, on one simulated device and network Real Chrome users, collected in the Chrome UX Report (CrUX)
Metrics LCP, CLS, TBT, FCP, Speed Index LCP, INP, CLS, plus FCP and TTFB
Available for Any URL, instantly Pages and origins with enough Chrome traffic
Best used for Debugging and checking a fix before release Confirming what visitors actually experience
Where to see it Super Site Report, Lighthouse in Chrome DevTools, PageSpeed Insights PageSpeed Insights, Search Console’s Core Web Vitals report

Lab and field numbers often disagree. A lab test on a throttled mobile profile can be slower than most real visitors, or faster than a large audience on older phones. Use the lab to find causes and the field data to judge success. Field data is a rolling 28-day window, so improvements take a few weeks to show up fully.

Do Core Web Vitals affect Google rankings?

Google lists Core Web Vitals as part of its page experience signals and describes them as aligned with what its core ranking systems seek to reward. The same documentation is clear that relevance comes first: a fast page will not outrank a much more useful one on speed alone. Treat Core Web Vitals as part of keeping visitors and as a tie-breaker in competitive results, not a shortcut. Google’s Core Web Vitals and Google Search page is the authoritative reference.

How do you check your Core Web Vitals?

  1. Run a scan. Super Site Report runs a mobile Lighthouse audit and shows LCP, CLS and TBT alongside the server checks that often explain them, such as slow TTFB, missing compression or no caching.
  2. Check field data. Enter the URL in PageSpeed Insights to see CrUX data if your site has enough traffic.
  3. Monitor in Search Console. The Core Web Vitals report groups similar URLs and flags which groups fail.
  4. Debug in DevTools. Chrome’s Performance panel shows long tasks, layout shifts and the LCP element for any page.

On WordPress, most fixes come from caching, lighter themes and fewer plugins; our WordPress speed guide goes through them step by step.

Frequently asked questions

What is a good Core Web Vitals score?

There is no single score. Each metric has its own threshold: LCP at most 2.5 seconds, INP at most 200 milliseconds and CLS at most 0.1, measured at the 75th percentile of visits. A page passes the assessment when all three are in the “good” range.

Why does PageSpeed Insights show no field data for my site?

Field data comes from the Chrome UX Report, which only includes pages and origins with enough eligible Chrome traffic. Smaller sites often have no field data. Lab results from Lighthouse or Super Site Report are still useful for finding problems.

Why do my Lighthouse scores change between runs?

Lighthouse results vary with network conditions, server load, third-party scripts and A/B tests. Run a few tests and look at the trend rather than a single number. Super Site Report caches each Lighthouse run so a report stays consistent until you rescan.

Is mobile or desktop more important?

Both are assessed separately. Google uses mobile-first indexing, and phones usually have slower CPUs and networks, so mobile results tend to be worse and deserve priority. Super Site Report tests mobile by default for that reason.

How long does it take for fixes to show in Search Console?

Field data uses a rolling 28-day window, so a fix appears gradually over about four weeks. Lab tests show the effect immediately, which is why they are useful for confirming a change before waiting for field data.

Sources