Core Web Vitals explained: LCP, INP and CLS, thresholds and how to pass

Core Web Vitals are three metrics Google uses to measure how a page feels to real visitors: Largest Contentful Paint (LCP) for loading, Interaction to Next Paint (INP) for responsiveness and Cumulative Layout Shift (CLS) for visual stability. A page passes when at least 75 % of real Chrome visits are "good" on all three: LCP within 2.5 s, INP within 200 ms and CLS at 0.1 or less. This guide is the map of the topic for site owners: what each metric means in visitor terms, where the numbers come from, how to check yours, and which guide to read next for the one that fails.

Quick answer

• The numbers that count come from real Chrome users (the Chrome UX Report), at the 75th percentile, over a rolling 28 days.
• A lab test such as Lighthouse explains the numbers but is not what Google assesses. It cannot measure INP at all.
• Fix the metric that is poor for real users, on the whole page template, not just one URL.
• A fix shows in full in the field data after about four weeks.
• Check any page with the free Core Web Vitals test, and see up to 40 weeks of history with the Core Web Vitals report.

What are Core Web Vitals?

Core Web Vitals are the part of Google's Web Vitals programme that it considers essential for every page. Google introduced them in 2020 to replace arguments about "fast" with three measurable questions a visitor would ask: is the main thing visible yet, does it react when I tap, and does it stay still while I read? Each has a threshold for "good", published on web.dev, and each is measured from real visits rather than from a test machine.

The set changes rarely, and only with notice. The original three were LCP, First Input Delay (FID) and CLS. On 12 March 2024 INP replaced FID, because FID only measured the delay before the first interaction was handled and missed pages that react slowly later. Since then the three Core Web Vitals metrics have been LCP, INP and CLS.

Core Web Vitals are not the same thing as page speed, or as the Lighthouse score. Page speed is the broader question of how fast a page loads and responds, with more metrics and more causes. The Lighthouse score is a lab blend of five metrics on a simulated phone. Core Web Vitals are the three field metrics Google reports in Search Console and uses in its ranking systems.

Core Web Vitals metrics and thresholds

Every metric is judged at the 75th percentile of page visits: the value three out of four visits stayed within. That rule is deliberate. A few visits on a train in a tunnel do not fail your page, but a quarter of visitors having a poor experience does. Mobile and desktop visits are assessed separately, and Search Console reports them separately.

The thresholds are Google's, from the web.dev pages for each metric:

• LCP: good at 2.5 s or less, poor above 4.0 s.
• INP: good at 200 ms or less, poor above 500 ms.
• CLS: good at 0.1 or less, poor above 0.25. CLS is a score without units.

A page or URL group passes the Core Web Vitals assessment when all three are good at the 75th percentile. One poor metric is enough to fail, which is why the order you fix them in matters (see "How do you pass the Core Web Vitals assessment?" below).

LCP: is the main content visible yet?

The browser watches the largest image or text block in the viewport as the page loads and records when it was painted. On a product page that is the product photo; on an article, the headline or the hero image; on a home page, the banner. Everything the browser must do before that paint counts: the server answering, the HTML arriving, CSS blocking the render, a web font that the headline waits for, and the image file itself.

Typical causes of a poor LCP, most common first:

1. The LCP image is large (a camera original) or served in an old format.
2. The LCP image is lazy-loaded, so it only starts downloading after the layout is done.
3. Render-blocking CSS or JavaScript in the <head> delays the first paint.
4. A slow server: a time to first byte over a second on shared hosting or an uncached CMS page.
5. A web font the headline waits for, with no font-display fallback.

The guide to Largest Contentful Paint: what it is and how to improve it splits LCP into its four parts (server, resource delay, download, render delay) and gives the fix for each, including how to preload the LCP image. If the hero is a video or a YouTube embed, read video on landing pages without killing LCP first: a poster image and a click-to-load player usually fix it.

INP: does it react when I tap?

Every time a visitor taps, clicks or types, the browser measures the time until the next frame is drawn. INP is close to the worst of those over the whole visit: the slowest interaction, ignoring one outlier for every 50 interactions on busy pages. Under 200 ms feels instant; over 500 ms feels broken, like a menu that opens a moment after you tapped it.

The cause is almost always JavaScript running on the main thread when the tap arrives: a tag manager firing tags, a heavy framework hydrating, an event handler that does too much (recalculating the whole page on every keystroke), or third-party scripts such as chat, A/B testing and ads competing for the same thread.

Sites that passed FID often fail INP, because INP counts every interaction until the screen updates, not only the wait before the first one. The guide to Interaction to Next Paint: what it is and how to improve it shows how to find the slow interaction with the browser's performance panel and how to break up long tasks. For the underlying mechanics, see long tasks and main-thread work and third-party scripts.

CLS: did the page jump?

Layout shift is when something visible moves without the visitor doing anything: the text jumps down when an image above it loads, a cookie banner pushes the page, a font swap makes a paragraph longer. Each shift is scored by how much of the viewport moved and how far. CLS takes the worst burst of shifts during the visit (shifts less than a second apart, in a window of up to five seconds) and adds them up. 0.1 is roughly "a tenth of the screen moved a little"; 0.25 is the page visibly rearranging itself.

The four usual causes:

1. Images and embeds without width and height, so the browser cannot reserve space.
2. Web fonts loading after the text was drawn in a fallback font of a different size.
3. Content injected above existing content: banners, notices, ads.
4. Animations that change layout properties (height, top) instead of transform.

Cumulative Layout Shift: what causes it and how to fix it walks through each cause with the CSS to copy; the first fix alone solves most sites. Fonts have their own guide, web fonts without layout shift.

The metrics around the vitals

Three supporting metrics show up in every report next to the vitals. They are not assessed on their own, but they explain a poor vital:

• Time to First Byte (TTFB): how long the server takes to start answering. LCP can never be faster than it. Google rates it good at 800 ms or less. TTFB: what a slow server looks like covers it.
• First Contentful Paint (FCP): when the first text or image appears. A slow FCP with a fast TTFB points at render-blocking files. See Speed Index and First Contentful Paint.
• Total Blocking Time (TBT): a lab measure of how long the main thread was blocked during load. It is the lab stand-in for INP, because a lab test does not tap anything.

Where the numbers come from: field data and lab data

Chrome sends anonymous timing data from real visits to Google, from users who have not opted out. The dataset is the Chrome UX Report (CrUX). Google aggregates it per URL and per origin over a rolling 28 days and reports the 75th percentile. That is the "field data" in Search Console, in PageSpeed Insights and in getReport, and it is what the Core Web Vitals assessment uses.

A lab tool such as Lighthouse loads the page once in a simulated phone and measures LCP and CLS directly. It cannot measure INP because it does not interact, so it reports TBT instead. Lab data is for diagnosis: it is repeatable, it names the LCP element, and it lists the files that cost the time.

Pages with little traffic have no field data of their own. Tools then show the origin's figures, all pages combined, and Search Console groups similar URLs together. A brand-new or very small site may have no field data at all, and the lab run is all you have.

The two often disagree, and each disagreement means something. The guide to field data vs lab data explains the four combinations and what to do in each. The short version: when they disagree, the field is the truth and the lab is the clue.

How to check your Core Web Vitals

Start with one page that matters, then look at the site:

1. One page, field and lab side by side. Run the Core Web Vitals test. It reads the CrUX field data for the URL and the origin and runs a Lighthouse lab test next to it.
2. The whole site. Search Console → Core Web Vitals groups your URLs into Good, Needs improvement and Poor, separately for mobile and desktop, for sites you have verified.
3. Over time. The Core Web Vitals report tool plots up to 40 weekly data points from the CrUX History API against the thresholds, so you can see the week a metric changed.
4. Your own visit. The Performance panel in Chrome's developer tools shows live LCP, INP and CLS as you use the page, which is how you find the slow interaction behind a poor INP.

The test shows bars for the share of visits in each band, the 75th percentile rated against Google's thresholds, and the lab values with the element responsible. The speed module's findings turn each lab audit into a fix.

A single test tells you where you stand; history tells you when it changed. A drop in Core Web Vitals usually has a date: a theme update, a new plugin, a heavier hero image, a new tag manager container. Core Web Vitals history: reading 40 weeks of CrUX shows how to read the chart, match a change to a release and confirm that a fix worked.

Reading your result

• All three good in the field: the page passes. Check the origin numbers too; low-traffic pages may be judged with their URL group.
• LCP poor, others good: a loading problem. The lab LCP element tells you what to fix.
• INP poor, lab TBT high: JavaScript during load. Look at the main-thread findings and third-party scripts.
• INP poor, lab TBT low: the lab did not trigger the slow interaction. It is something visitors do: open the menu, use the search, add to cart. Test those interactions in the browser's performance panel.
• CLS poor, lab CLS low: a shift that happens later in the visit: a late ad, a sticky banner, a font on a part of the page the test did not scroll to. The lab measures only the load.
• No field data: not enough traffic on that URL. Use the origin, or the lab data as a proxy.

How do you pass the Core Web Vitals assessment?

Passing means all three metrics good at the 75th percentile for the URL group, on mobile and on desktop. The order that works:

1. Find the failing metric in the field data, not the lab score. Search Console tells you which metric and which URL group.
2. Fix it on the template. Search Console groups similar pages; the product or article template usually matters more than the home page.
3. LCP first if more than one fails. It affects most pages and has the clearest fixes: a fast server with page caching, a compressed hero image that is not lazy-loaded, and fewer render-blocking files.
4. INP next: less JavaScript on the main thread, fewer third-party tags, lighter event handlers.
5. CLS last, often the quickest: dimensions on images, reserved space for ads and embeds, fonts that do not reflow.
6. Wait and verify. The lab value improves immediately; the field value follows over 28 days. Search Console's "Validate fix" runs for the same 28 days.

The guide on how to improve Core Web Vitals turns this into a working plan: a triage table that matches a failed metric and what the lab shows to its likely cause, the fixes for each part of LCP, INP and CLS, and how to use Search Console's Validate fix. The general speed fixes, in order of impact, are in the page speed guide.

Core Web Vitals and SEO

Google's Search Central documentation says Core Web Vitals are used by its ranking systems, as part of page experience, and that it still shows the most relevant content even when page experience is sub-par. Good scores do not guarantee top rankings. In practice they work like a tie-breaker between pages of similar relevance, judged only on field data from real Chrome visitors, never on a Lighthouse score.

The guide to how Core Web Vitals affect SEO and rankings covers what Google has said since the 2021 page experience update, how much the vitals count next to content, what to expect after a fix and when they are worth prioritising for search. For speed as a whole, see the page speed guide.

The bigger effect is on visitors. A page that shows its content late, reacts slowly or jumps under the finger loses people before they read, sign up or buy, whatever its position.

Core Web Vitals by type of site

The metrics are the same everywhere, but the usual culprit depends on what the site is:

Online shops. Product pages fail LCP on the gallery image and INP on variant pickers and add-to-cart; category pages fail CLS on filters and lazy-loaded tiles. Core Web Vitals for e-commerce product and category pages covers both templates.

News and publisher sites. Ads, embeds and consent banners are the main source of layout shift, and ad scripts are the main source of poor INP. Core Web Vitals for news sites shows how to reserve ad slots and keep embeds from moving the article.

Landing pages with video. An autoplaying hero video or an embedded player is often the LCP element and one of the heaviest things on the page. Video on landing pages without killing LCP gives the lightweight patterns.

WordPress. Most WordPress sites fail on the same few things: no page cache, a heavy page builder, plugins loading scripts on every page and slow shared hosting. Core itself helps: it lazy-loads images below the fold, adds fetchpriority="high" to the likely LCP image and prefetches pages on click. The trouble starts when a slider, builder or plugin overrides that, for example by lazy-loading the first slide.

WordPress Core Web Vitals goes metric by metric: the server and hero-image causes of a poor LCP, the plugin and builder scripts behind a poor INP, and the cookie banners, ads and fonts that fail CLS. The settings guides for WP Rocket and LiteSpeed Cache cover the two most common caching plugins.

Verify

• Search Console → Core Web Vitals shows the URL group as Good for mobile and desktop.
• The field bars in the Core Web Vitals test match Search Console; both read CrUX, with a day or two of lag.
• The history chart shows the line crossing back into the good band in the weeks after your fix.
• After a fix, the lab value improves at once; the field value follows over the next four weeks.

Common mistakes

• Reading the lab score as the assessment. Google uses the field data. A lab score of 100 does not mean the page passes.
• Expecting field numbers to change the day after a fix. They cover 28 days.
• Fixing the home page only. Search Console groups similar URLs; the product or article template matters more.
• Looking at desktop only. Mobile is assessed separately and is usually the one that fails.
• Chasing 100. Under the thresholds is the goal; the last few points cost more than they return.
• Adding scripts to measure performance that themselves make INP worse. CrUX and the browser's own tools cost nothing.

Questions people ask

What are Core Web Vitals?

Core Web Vitals are three measurements Google uses to judge how a page feels to real visitors: Largest Contentful Paint (LCP, loading, good at 2.5 s or less), Interaction to Next Paint (INP, responsiveness, 200 ms or less) and Cumulative Layout Shift (CLS, visual stability, 0.1 or less). They are measured from real Chrome users at the 75th percentile over 28 days, and Google uses them in its ranking systems.

Which Core Web Vital fails most often?

LCP. The HTTP Archive's 2025 Web Almanac, based on mid-2025 Chrome UX Report data, found that 62 % of sites had a good LCP on mobile, against 77 % for INP and 81 % for CLS. So if your site fails, loading is the likeliest reason: a slow server response, a large or lazy-loaded hero image, or render-blocking files. Check the field data to be sure before you start fixing.

Is the Lighthouse score part of Core Web Vitals?

No. The Lighthouse performance score is a 0-100 lab blend of five metrics from one simulated visit on a throttled phone. Core Web Vitals are three field metrics, LCP, INP and CLS, measured from real Chrome visitors at the 75th percentile over 28 days. Lighthouse cannot measure INP because it never taps the page. Use the lab score to find causes and the field data to judge whether the page passes.

Do Core Web Vitals apply to pages with little traffic?

Yes, but they are judged with more data than the page has on its own. The Chrome UX Report only publishes numbers for URLs with enough Chrome visits, so a low-traffic page is assessed with its group of similar URLs in Search Console, or with the whole origin in PageSpeed Insights. A slow template therefore counts against every quiet page built on it, even pages with no data of their own.

How do I check Core Web Vitals?

Run a Core Web Vitals test on the page: it shows the field data from real Chrome users for the URL and the whole origin next to a lab run that explains the numbers. Search Console's Core Web Vitals report groups your URLs as Good, Needs improvement or Poor across the site. Pages without enough traffic have no field data of their own and are judged with the origin or their URL group.

What is FID in Core Web Vitals?

FID (First Input Delay) was the original responsiveness metric in Core Web Vitals. It measured only the delay before the browser began handling the first tap or click. Google replaced it with Interaction to Next Paint (INP) on 12 March 2024, because INP covers every interaction during the visit and the time until the screen actually updates. FID is no longer reported; if a tool still shows it, look at INP instead.

Do Core Web Vitals measure the whole visit or only the page load?

Two of the three cover the whole visit. INP looks at every click, tap and key press until the visitor leaves, and CLS counts layout shifts at any time, grouped into bursts. LCP is the exception: it stops at the first interaction or scroll. That is why lab tests, which only load the page, can miss slow menus and late banners that real visitors see; see Cumulative Layout Shift for the late-shift causes.

Why do my Core Web Vitals differ between mobile and desktop?

Because Google measures them separately, from real phone visits and real desktop visits, and the two groups have different devices and networks. Phones have slower processors, so the same JavaScript takes longer and INP suffers; mobile connections are slower and less stable, which hurts LCP. Search Console reports each separately, and a page can pass on desktop while failing on mobile. Work on the mobile numbers first.