Core Web Vitals: what LCP, INP and CLS measure and how to fix them

What Core Web Vitals are

Google Search Central defines them in one sentence: “Core Web Vitals is a set of metrics that measure real-world user experience for loading performance, interactivity, and visual stability of the page.” There are three of them, and each answers one question a visitor has:

• Largest Contentful Paint (LCP): how quickly does the main content appear? It is the time until the largest image, text block or video in the viewport is rendered.
• Interaction to Next Paint (INP): when I click, tap or type, how quickly does the page react on screen?
• Cumulative Layout Shift (CLS): does the content jump around while I am reading or about to click?

INP replaced FID in March 2024

Until 2024 the responsiveness metric was First Input Delay (FID). FID only looked at the delay before the browser started handling the first interaction. INP looks at the interactions throughout the visit and measures the full time until the next frame is painted. Google's web.dev announced: “Interaction to Next Paint will officially become a Core Web Vital and will replace First Input Delay on March 12.” That was 12 March 2024. If a tool, plugin or article still talks about FID as a Core Web Vital, it is out of date.

How metrics get added and retired

“Metrics on the Core Web Vitals track go through a lifecycle consisting of three phases: experimental, pending, and stable.” INP went through all three before it replaced FID. Today LCP, INP and CLS are all stable. The set can still change in future, but changes are announced in advance.

The thresholds and the 75th percentile rule

Each metric has three bands. These are the ranges Search Console uses in its Core Web Vitals report:

The 75th percentile

A metric is not judged on one visit or on the average. Google's web.dev explains: “To ensure you're hitting the recommended target for these metrics for most of your users, a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices.” In plain terms: sort all visits from fastest to slowest and take the value three-quarters of the way along. If that value is within the “good” band, at least 75% of your visitors had a good experience on that metric.

Three consequences follow:

1. All three must pass. “Tools that assess Core Web Vitals compliance should consider a page passing if it meets the recommended targets at the 75th percentile for all three of the Core Web Vitals metrics.” Good LCP and CLS do not compensate for poor INP.
2. Mobile and desktop are judged separately. A page can be good on desktop and poor on mobile. Mobile visitors usually have slower devices and networks, so mobile is where most pages fail.
3. Your slowest quarter matters less, but not nothing. A few very slow visits will not fail a page, but if the slow visits grow past a quarter of traffic, the 75th percentile value moves into the next band.

What Google officially says

The same page experience documentation adds several limits. Each of these is a direct quote:

• “There is no single signal.”
• “getting good results in reports like Search Console's Core Web Vitals report or third-party tools doesn't guarantee that your pages will rank at the top of Google Search results; there's more to great page experience than Core Web Vitals scores alone.”
• “trying to get a perfect score just for SEO reasons may not be the best use of your time.”
• “Beyond Core Web Vitals, other page experience aspects don't directly help your website rank higher in search results.”
• “Our core ranking systems generally evaluate content on a page-specific basis, including when understanding aspects related to page experience. However, we do have some site-wide assessments.”

Google also gives a self-assessment for page experience. Among its questions: “Do your pages have good Core Web Vitals?” “Are your pages served in a secure fashion?” “Does your content display well on mobile devices?” “Do your pages avoid using intrusive interstitials?”

How much Core Web Vitals matter for ranking

Read Google's wording carefully and a consistent picture emerges:

• They are used. Core Web Vitals are part of what Google's ranking systems look at. Ignoring them completely is not a sensible plan.
• Relevance wins. A highly relevant page with poor Core Web Vitals can still outrank a fast page that answers the query worse. Speed does not rescue weak content.
• They help most when the competition is close. Google says a great page experience can contribute to success when “there is lots of helpful content available”. On competitive queries with many good answers, experience is one of the things that can separate them.
• Good is enough. Google does not reward chasing a perfect score. Moving from “poor” to “good” is the work that counts; shaving a good LCP from 2.0 to 1.5 seconds is a user-experience decision, not an SEO one.
• Mostly page by page. Ranking systems generally assess page experience per page, with “some site-wide assessments”. Fixing a slow template therefore improves every page built on it.

The other page experience aspects in the self-assessment, such as HTTPS, mobile-friendliness and avoiding intrusive interstitials, are worth doing for users. Google states they do not directly raise rankings on their own.

Field data vs lab data

There are two ways to measure performance, and they answer different questions.

Field data comes from real visits. Google's main field source is the Chrome User Experience Report (CrUX), which collects anonymised measurements from Chrome users. This is the data shown in the Search Console report and in the top section of PageSpeed Insights, and it reflects your real visitors' devices, networks and locations. As web.dev puts it: “The most important thing to understand about field data is that it is not just one number, it's a distribution of numbers.”

Lab data comes from loading a page once in a controlled environment, usually with Lighthouse (inside PageSpeed Insights and Chrome DevTools). It is repeatable and detailed, which makes it ideal for debugging and for testing a fix before release. But it is one simulated visit, not your audience.

Lab tools cannot measure INP at all: “Tools like Lighthouse that load pages in a simulated environment without a user cannot measure INP, as there is no user input.” Lighthouse reports Total Blocking Time instead, which tends to move in the same direction. And because users scroll, click and stay on pages longer than a test run, field CLS is often higher than lab CLS.

If your site gets little traffic, CrUX may have no data for it at all. In that case rely on lab data and, if you can, collect your own field data with the open-source web-vitals JavaScript library (real user monitoring, or RUM).

LCP: causes and fixes

“LCP reports the render time of the largest image, text block, or video visible in the viewport, relative to when the user first navigated to the page.” On most pages the LCP element is a hero image, a product photo or the main heading. Lighthouse and DevTools tell you which element it is on your page.

To fix LCP, split it into parts. web.dev says: “Every single page can have its LCP value broken down into these four subparts.”

The two “delay” parts should be close to zero on a well-built page. If either is large, that is where to start.

Time to first byte (TTFB)

The time until the browser receives the first byte of the HTML. Nothing else can start before it. Fixes: full-page caching, a CDN, faster hosting or database queries, and removing redirect chains (each redirect adds a round trip before the real page loads).

Resource load delay

The gap between the first byte and the moment the browser starts downloading the LCP image. It grows when the browser discovers the image late. Fixes:

• Put the hero image in the HTML as an <img>, not as a CSS background or an element inserted by JavaScript.
• Never add loading="lazy" to it. Google's guidance is direct: “Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay, and will have a negative impact on LCP.”
• Add fetchpriority="high" to the LCP image so the browser downloads it before less important files.
• If the image can only be referenced from CSS, preload it with <link rel="preload" as="image" fetchpriority="high">.

Resource load duration

How long the image itself takes to download. Fixes: compress it, use AVIF or WebP, serve the right size with srcset and sizes, and deliver it from a CDN. On its own this is not enough: web.dev shows that a smaller image can simply move the waiting time into render delay if the page is blocked elsewhere.

Element render delay

The time between the image finishing and it appearing on screen. Fixes: reduce render-blocking CSS and JavaScript in the <head>, inline the critical CSS, avoid rendering the hero only after a JavaScript framework has loaded, and remove A/B testing or “anti-flicker” scripts that hide the page until they finish. If the LCP element is text, make sure the web font does not keep it invisible.

<!-- discovered late, loaded late -->
<img src="/img/hero.jpg"
     loading="lazy"
     alt="Running shoes">

/* or hidden in CSS */
.hero { background: url(/img/hero.jpg); }

<img src="/img/hero-800.webp"
     srcset="/img/hero-800.webp 800w,
             /img/hero-1600.webp 1600w"
     sizes="100vw"
     width="1600" height="900"
     fetchpriority="high"
     alt="Running shoes">

INP: causes and fixes

INP observes clicks, taps and key presses during the whole visit. Hovering, scrolling and zooming do not count. For each interaction it measures the time until the browser paints the next frame, and “The final INP value is the longest interaction observed, ignoring outliers.” So one slow menu or one slow “Add to cart” button can decide the page's INP.

Every interaction has three phases:

1. Input delay: the browser is busy with something else and cannot start handling your click yet.
2. Processing duration: your event handlers run.
3. Presentation delay: the browser recalculates styles and layout and paints the result.

The common root cause is long tasks on the main thread: blocks of JavaScript that run for more than 50 milliseconds without a break. While one runs, the page cannot respond. Causes and fixes by phase:

Input delay

Usually caused by heavy scripts running while the page loads, or by timers and third-party tags firing in the background. Fixes: load less JavaScript, defer what is not needed for the first view, split large bundles, and audit tag managers, chat widgets and ad scripts. Interactions during page load are often the slowest, so test those too.

Processing duration

Caused by event handlers that do too much. Google's advice: “The best general advice in optimizing event callbacks is to do as little work as possible in them.” Do the visible update first (open the menu, show a spinner) and move the rest, such as analytics calls or saving state, to a separate task. Debounce handlers on inputs that fire often, like typing in a search box.

button.addEventListener('click', () => {
  showMenu();                 // the user sees this immediately
  setTimeout(() => {           // yield, then do the rest
    sendAnalytics();
    saveState();
  }, 0);
});

Presentation delay

Caused by a large DOM, complex CSS selectors and updates that force the browser to redo layout many times. Fixes: keep the number of elements down (paginate long lists, do not render hidden mega-menus in full), avoid reading and writing layout properties in a loop, and update only the part of the page that changed. Pages that render most of their HTML with JavaScript on the client are especially prone to slow interactions.

CLS: causes and fixes

CLS adds up how much visible content moves unexpectedly, and how far. Shifts are grouped into short bursts, and CLS is the score of the worst burst during the visit. Movement the user caused is excluded: “Layout shifts that occur within 500 milliseconds of user input will have the hadRecentInput flag set, so they can be excluded from calculations.” Opening an accordion you clicked does not hurt CLS; a banner that appears on its own and pushes the text down does.

One more tip from web.dev: make your pages eligible for the back/forward cache (bfcache). A page restored from bfcache appears exactly as the user left it, without any new shifts.

Tools: PageSpeed Insights, Search Console, Chrome DevTools

A practical split: Search Console tells you where the problem is, PageSpeed Insights confirms it for a sample URL, and DevTools shows you why.

The Core Web Vitals report in Search Console

The report lives under Experience in Search Console. “The data for the Core Web Vitals report comes from the CrUX report”, so it shows what real visitors experienced over the last 28 days, not a test.

URL groups

“URLs in the report are grouped into pages that have a similar user experience.” Typically these are pages built on the same template, such as all product pages or all blog posts. The status applies to the whole group, and the example URL you see represents the group. If a group has too little data, Search Console falls back to an origin group for the whole protocol://host:port, for example everything under https://example.com.

How the report works

• Status is the worst metric. “Once a URL group has a threshold amount of data for both LCP and CLS, the URL group's status is its most poorly performing metric.” A group without enough data for both LCP and CLS is left out.
• Mobile and desktop are separate reports, with separate statuses for the same group.
• Only indexed URLs. “Only indexed URLs can appear in this report.” The report shows a sample of URLs, not every page.
• Actual URL, not canonical. “Data is assigned to the actual URL, not the canonical URL”, unlike most other Search Console reports. URLs with parameters can appear separately.
• Group values are percentiles. Group LCP, INP and CLS are the values 75% of visits in the last 28 days met or beat.
• “No data available” means the property is new or CrUX does not have enough visits for that device type. It is normal for small sites.
• PageSpeed Insights may disagree. The report works with groups, PSI with single URLs, and “PageSpeed Insights strips all parameter data from the URL, and then assigns all results to the bare URL.”

Prioritising and validating

Google recommends “fixing everything labeled "Poor" first”, then working through issues by the number of URLs affected or by the importance of the pages. After deploying a fix, click Validate fix (Start tracking): “Click Start Tracking to start a 28-day monitoring session to check for instances of this issue in your site.” If the issue does not appear on any URL during those 28 days, it is marked as fixed. Note that “Start tracking does not trigger re-indexing or any other active behavior from Google.” It only watches the field data.

If many pages change status without any change on your side, look for borderline values: a traffic spike, a slower image server or a shift in your audience's devices can push groups that were just inside “good” over the line.

Common mistakes

• ✕Optimising the Lighthouse scoreThe 0–100 score is a lab number. Google's ranking systems use field data, and Search Console shows field data only.
• ✕Still tracking FIDINP replaced FID on 12 March 2024. Tools and dashboards that report FID as a Core Web Vital are outdated.
• ✕Checking desktop onlyMobile and desktop are assessed separately, and mobile is usually where pages fail.
• ✕Lazy-loading the hero imageA blanket loading="lazy" on all images delays the LCP element. Exclude above-the-fold images.
• ✕Images without width and heightThe single most common cause of layout shifts, and the easiest to fix in a template.
• ✕Ad slots that collapse or growUnreserved ad space pushes the content down as ads load.
• ✕Testing only an empty page loadINP and much of CLS happen when people interact and scroll. Click menus, filters and buttons while you test.
• ✕Expecting results the next dayField data covers 28 days, so improvements appear gradually and validation takes four weeks.
• ✕Treating Core Web Vitals as the main ranking leverGoogle says relevance comes first. A fast page with weak content will not outrank a better answer.

How to improve Core Web Vitals step by step

1. Open the Search Console report, mobile first, and list the issues labelled Poor with their example URLs.
2. Map groups to templates. Product pages, category pages, articles: one template usually explains a whole group.
3. Confirm with PageSpeed Insights on one or two example URLs. Check the field section and note which metric fails.
4. Diagnose in the lab. Use Lighthouse and the DevTools Performance panel to find the LCP element and its subparts, long tasks during interactions, and the elements that shift.
5. Fix the template, starting with the cheapest high-impact fixes: image dimensions, removing lazy loading from the hero, fetchpriority, reserved ad space, deferred third-party scripts.
6. Verify in the lab before and after release, on a throttled mobile profile.
7. Click Validate fix in Search Console and watch the 28-day field data.
8. Set up monitoring with the web-vitals library or a RUM tool so regressions from new scripts or features are caught early.

FAQ

Sources

• Google Search Central — Understanding Core Web Vitals and Google search results
• Google Search Central — Understanding page experience in Google Search results
• Google Search Console Help — Core Web Vitals report
• web.dev (Google) — Web Vitals
• web.dev (Google) — Largest Contentful Paint and Optimize LCP
• web.dev (Google) — Interaction to Next Paint and Optimize INP
• web.dev (Google) — Cumulative Layout Shift and Optimize CLS
• web.dev (Google) — Interaction to Next Paint becomes a Core Web Vital on March 12
• web.dev (Google) — Why lab and field data can be different

Quotes checked against the official pages on 30 October 2026.