There are three Core Web Vitals: Largest Contentful Paint (LCP) for loading, which should be 2.5 seconds or less; Interaction to Next Paint (INP) for responsiveness, which should be 200 milliseconds or less; and Cumulative Layout Shift (CLS) for visual stability, which should be 0.1 or less. A page passes when all three hit those targets for at least 75% of real visits.
Core Web Vitals are the three numbers Google uses to judge how a page feels to real visitors: how fast the main content shows up, how quickly the page responds to taps and clicks, and whether things jump around while it loads. They also show up in PageSpeed Insights, Search Console and most audit tools, often with confusing differences between them. This guide explains what each metric measures, the exact thresholds in use today, and how to read field data and lab data without chasing the wrong number.
Key takeaways
- Good Core Web Vitals are an LCP of 2.5 s or less, an INP of 200 ms or less and a CLS of 0.1 or less.
- A page passes only when all three metrics are good at the 75th percentile of real page loads, measured separately for mobile and desktop.
- Trust field data from the Chrome User Experience Report to find problems, and use Lighthouse lab data to work out why.
- Field data covers a rolling 28-day window, so fixes take about four weeks to show fully in Search Console.
What are the types of Core Web Vitals?
There are three types of Core Web Vitals, one for each part of the experience: LCP for loading (good is 2.5 seconds or less), INP for interactivity (good is 200 milliseconds or less) and CLS for visual stability (good is 0.1 or less). Each is measured at the 75th percentile of real page loads, and the thresholds below are the ones published on web.dev, Google's developer site.
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Loading: when the largest visible image or text block renders | 2.5 s or less | 2.5 s to 4.0 s | Over 4.0 s |
| INP (Interaction to Next Paint) | Responsiveness: delay between a tap, click or key press and the next frame | 200 ms or less | 200 ms to 500 ms | Over 500 ms |
| CLS (Cumulative Layout Shift) | Visual stability: how much visible content moves unexpectedly | 0.1 or less | 0.1 to 0.25 | Over 0.25 |
All three are currently labelled Stable. Web.dev describes a lifecycle of three phases (experimental, pending and stable) and says stable Core Web Vitals "won't change more than once per year". The last change was on March 12, 2024, when INP replaced First Input Delay (FID) as the responsiveness metric. If a guide or plugin still lists FID as one of the three, it predates that change.
Core Web Vitals vs other web vitals
You will also see metrics such as Time to First Byte (TTFB), First Contentful Paint (FCP) and Total Blocking Time (TBT) in reports. Web.dev describes these as supporting metrics that act as proxies or supplements for the three Core Web Vitals. TTFB and FCP help you diagnose a slow LCP, and TBT is a lab metric that helps you catch problems that will show up as a poor INP. None of them is a Core Web Vital, and none of them decides whether a page passes.
What is LCP in Core Web Vitals?
LCP, or Largest Contentful Paint, is the loading metric. It measures how long the largest image, text block or video visible in the viewport takes to render, counted from when the visitor started loading the page. A good LCP is 2.5 seconds or less, and anything over 4.0 seconds is poor.
In other words, LCP marks the moment the biggest content element in the viewport finishes rendering. On most pages that is a hero image, a product photo or the main headline paragraph.
Elements that can count as the LCP element:
<img>elements, and<image>inside an<svg><video>elements (the poster image or first frame, whichever is earlier)- Elements with a CSS
background-image: url(...)(gradients do not count) - Block-level elements containing text
Chromium also ignores some elements on purpose: invisible elements with opacity: 0, elements that cover the whole viewport (treated as backgrounds), and low-entropy placeholder images.
A slow LCP is usually caused by one of four things: a slow server response, an image that the browser discovers late, a large image file, or render-blocking CSS and JavaScript. Our guide to improving Largest Contentful Paint walks through each one.
What is INP in Core Web Vitals?
INP, or Interaction to Next Paint, is the responsiveness metric. It measures how long the page takes to visually respond after a visitor interacts with it, looking at interactions across the whole visit rather than just the first. A good INP is 200 milliseconds or less, and anything over 500 milliseconds is poor.
Only three kinds of input count: mouse clicks, touchscreen taps and key presses. Hovering and scrolling are not measured.
Every interaction has three parts:
- Input delay - the time before your event handlers can start, usually because the main thread is busy with other JavaScript.
- Processing duration - the time your event handlers take to run.
- Presentation delay - the time from the handlers finishing until the browser paints the next frame.
INP reports roughly the slowest interaction during the whole visit. On pages with lots of interactions, one of the highest values is ignored for every 50 interactions, so a single freak outlier does not define the score.
Why INP replaced FID
FID only measured the input delay of the first interaction. A page could pass FID and still feel sluggish every time someone opened a menu or filtered a list. INP looks at all interactions and the full time until the screen updates. It officially became a Core Web Vital on March 12, 2024, and FID was later removed from Chrome's tools. If you still see FID mentioned in a report or plugin, that tool is out of date.
For fixes, see how to fix a slow INP.
What is CLS in Core Web Vitals?
CLS, or Cumulative Layout Shift, is the visual stability metric. It measures how much visible content moves unexpectedly while someone uses the page, such as a button sliding down just as you go to tap it. A good CLS is 0.1 or less, and a score above 0.25 is poor. Unlike the other two, CLS is a unitless score rather than a time.
Each individual shift gets a score:
layout shift score = impact fraction x distance fraction
- Impact fraction is how much of the viewport the moving elements cover (before and after the move combined).
- Distance fraction is how far they moved, relative to the viewport's largest dimension.
Shifts are grouped into "session windows": bursts of shifts less than 1 second apart, capped at 5 seconds per window. Your CLS is the total of the worst window, not the sum of every shift in the visit.
Shifts that happen within 500 ms of a tap, click or key press are excluded, because users expect the page to change when they act. Scrolling does not count as input, so content that jumps while someone scrolls still hurts the score.
The usual causes are images without dimensions, late-loading ads and embeds, web fonts swapping in, and banners injected above existing content. See fixing Cumulative Layout Shift.
How "passing" is decided: the 75th percentile
Google does not use your average. For each metric it takes the 75th percentile of real page loads, separately for mobile and desktop. A page passes Core Web Vitals only when all three metrics are in the "good" range at that percentile.
In practice: if 30% of your mobile visitors see an LCP over 2.5 seconds, you fail LCP on mobile, even if your median visitor gets a fast page. This is deliberate. It makes you design for the slower phones and weaker connections in your audience, not the best case.
Field data vs lab data
This is where most confusion comes from.
Field data (real users)
Field data comes from the Chrome User Experience Report (CrUX), which collects anonymized measurements from real Chrome users who have opted in. PageSpeed Insights shows CrUX data covering the previous 28 days, updated daily. Search Console's Core Web Vitals report also uses it.
Key points:
- Field data is what Google uses for page experience. It is the number that matters.
- Because it is a 28-day rolling window, a fix you deploy today takes weeks to fully show up.
- If an individual URL lacks enough traffic, PageSpeed Insights falls back to origin-level data (your whole site). Small sites may have no field data at all.
Lab data (a simulated test)
Lab data comes from Lighthouse running a single simulated page load from a Google data center, with throttled CPU and network for the mobile test. It is repeatable enough for debugging and gives you diagnostics, but it is one synthetic visit, not your audience.
Two important gaps:
- Lab tests cannot measure INP, because nobody is clicking anything. Lighthouse uses Total Blocking Time (TBT) as a proxy: the time the main thread was blocked by long tasks during load. High TBT usually means poor INP, but they are not the same.
- Lab CLS only covers the initial load. Shifts caused by scrolling, cookie banners after a delay, or ads that load later often appear only in field data.
When they disagree
| Situation | Likely explanation |
|---|---|
| Lab is bad, field is good | Your real visitors are on faster devices or connections than the throttled lab profile, or they hit cached pages. |
| Lab is good, field is bad | Real users have slower phones, come from far-away regions, interact a lot (INP), or see ads and consent banners the lab test missed. |
| Field shows "no data" | Not enough Chrome traffic for CrUX. Use lab data plus your own real-user monitoring. |
When they conflict, trust field data for "is there a problem?" and use lab data for "why?".
Where to check your Core Web Vitals
- PageSpeed Insights - field data at the top (if available), Lighthouse lab results below. Our post on why the PageSpeed score fluctuates explains how to read it.
- Our free PageSpeed checker - the same Google data for mobile and desktop on one screen, with each Core Web Vital rated good, needs improvement or poor. For a step-by-step testing method, see how to check website speed.
- Search Console > Core Web Vitals - groups of URLs with the same issue, based on field data. Best for spotting site-wide patterns.
- Chrome DevTools > Performance panel - shows live LCP, INP and CLS values as you use the page locally.
- The
web-vitalsJavaScript library - lets you collect your own real-user data and send it to analytics. - An audit tool - you can run a free audit with MakeItFlow to see your PageSpeed score and Core Web Vitals alongside SEO, security and DNS checks in one report.
Do Core Web Vitals affect rankings?
They are part of Google's page experience signals, and Google recommends achieving good Core Web Vitals. But Google does not say good scores guarantee better rankings, and relevance of content still matters far more. Treat Core Web Vitals as a tiebreaker and, more importantly, as a conversion issue: slow, jumpy pages lose visitors regardless of where they rank.
Frequently asked questions
What are the three types of Core Web Vitals?
Largest Contentful Paint (LCP) measures loading, Interaction to Next Paint (INP) measures responsiveness to clicks, taps and key presses, and Cumulative Layout Shift (CLS) measures visual stability. Good scores are an LCP of 2.5 seconds or less, an INP of 200 ms or less and a CLS of 0.1 or less.
What is LCP in Core Web Vitals?
LCP (Largest Contentful Paint) is the loading metric. It records when the largest image, video or text block in the viewport finishes rendering, measured from the start of the page load. Good is 2.5 seconds or less.
What is INP in Core Web Vitals?
INP (Interaction to Next Paint) is the responsiveness metric. It measures the delay between a click, tap or key press and the next frame the browser paints, across the whole visit. Good is 200 ms or less. INP replaced FID on March 12, 2024.
What is CLS in web vitals?
CLS (Cumulative Layout Shift) is the visual stability metric. It scores how much visible content shifts unexpectedly, taking the worst burst of shifts during the visit. Good is 0.1 or less.
What is a good LCP score?
2.5 seconds or less at the 75th percentile of real page loads. Between 2.5 and 4.0 seconds needs improvement, and over 4.0 seconds is poor. Check mobile and desktop separately, because mobile is often the slower of the two.
Do I need to pass all three Core Web Vitals?
To get a "passed" assessment, yes. All three metrics must be in the good range at the 75th percentile for that device type. You can pass on desktop and fail on mobile, which is common.
Why does PageSpeed Insights say "no data" for my site?
CrUX only publishes data for pages and origins with enough eligible Chrome traffic. Low-traffic pages fall back to origin data, and very small sites may have none. In that case rely on lab data and consider collecting your own measurements with the web-vitals library.
How long until my fixes show up in Search Console?
Field data covers a rolling 28-day window, so improvements phase in gradually over about four weeks. Lab tools reflect changes immediately, which is useful for confirming a fix before the field data catches up.
Is Total Blocking Time a Core Web Vital?
No. TBT is a lab metric that Lighthouse uses because it cannot measure real interactions. It correlates with INP and carries significant weight in the Lighthouse score, but Google's pass or fail assessment uses INP from real users.
Is FID still used anywhere?
No. INP replaced FID as a Core Web Vital on March 12, 2024, and FID was removed from Chrome tools including CrUX afterward. Any report still showing FID is using outdated data or software.
What to do next
Open PageSpeed Insights for your top landing page on mobile and note which of the three metrics is failing in the field data. Fix the worst one first, using the matching guide above, then re-test in the lab to confirm before waiting on the 28-day field window. To track Core Web Vitals over time, the website speed test records PageSpeed and Core Web Vitals results with every audit. If you want the performance results in context with the rest of your site's health, run a free audit and work through the prioritised fix list.
Related reading
- Chrome Adds Ad Metrics to CrUX: What Publishers Should Know: Chrome added four experimental ad metrics to CrUX on 15 September 2026. What ad count, density and weight mean for your site, and whether they affect rankings.
- WordPress Core Web Vitals: Which Plugins Actually Help: Improve WordPress Core Web Vitals with the right plugin types for LCP, INP and CLS, a before-and-after testing method, and the plugin overlaps to avoid.
Sources
Written by the MakeItFlow team
We build the website audit these guides are based on. Every fact is checked against the primary sources listed above and this guide was last reviewed on 30 October 2026 . How we research and check
Check your own site in 30 seconds
Run a free audit covering speed, SEO, DNS, email authentication and security headers — and get a prioritised fix list.
