Core Web Vitals Explained: LCP, INP and CLS
On this page
Core Web Vitals are three measurements Google uses to describe how a page feels to real visitors: how fast the main content loads, how quickly the page responds when someone taps or types, and how steady the layout stays while it loads. They are Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS). This explainer is part of our website design best practices guide.
Below, we cover what each metric measures, the thresholds that count as good, the difference between field and lab data, and how much the scores matter for search.
Key takeaways
- Core Web Vitals are three metrics: LCP for loading, INP for responsiveness and CLS for visual stability.
- Good means LCP within 2.5 seconds, INP of 200 ms or less and CLS of 0.1 or less.
- A page passes when 75% of real visits meet all three targets, on mobile and desktop.
- Field data from real Chrome users decides the score; lab tests help you find causes.
- Google uses them in ranking, but good scores don't replace relevant, helpful content.
What the three metrics measure
Each metric covers one part of the experience. Google and the Chrome team publish the definitions and thresholds on web.dev, and they apply to any site, whatever it's built with.
| Metric | What it measures | Good | Poor |
|---|---|---|---|
| Largest Contentful Paint (LCP) | When the largest image or text block renders | 2.5 seconds or less | Over 4 seconds |
| Interaction to Next Paint (INP) | Delay from a tap, click or key to the next frame | 200 ms or less | Over 500 ms |
| Cumulative Layout Shift (CLS) | How much visible content moves unexpectedly | 0.1 or less | Over 0.25 |
LCP times the moment the largest image, video or text block visible in the viewport is rendered, counted from when the visitor started loading the page. That includes redirects and server response time, not just the image download. On most marketing pages, the LCP element is the hero image or the main headline.
INP looks at the interactions during a visit, such as opening a menu or submitting a form. Each one has three parts: the input delay before the event handler starts, the time the handler takes to run, and the delay before the next frame is painted. The page's INP is worked out when the visitor leaves, so it reflects the whole visit, not just the first click.
CLS adds up unexpected layout shifts, such as text jumping down when an image or a banner loads above it. Shifts are grouped into bursts, and the score is the largest burst during the visit. Shifts that happen just after a tap or click don't count, because people expect the page to change then.
Thresholds and the 75th percentile
A single fast load proves little, because visitors use different phones, networks and browsers. So Google judges each metric at the 75th percentile of page visits, measured separately for mobile and desktop. If at least 75% of visits meet the good threshold, that metric is good.
A page passes the Core Web Vitals assessment only when all three metrics are good at the 75th percentile. Between good and poor is a middle band labelled "needs improvement". In practice, this means your slowest quarter of visits decides the result. Those are often people on older phones or patchy mobile connections, so test on a mid-range phone, not only on a fast laptop.
The set of metrics also changes over time. Metrics move through experimental, pending and stable phases before they become, or stop being, Core Web Vitals. INP replaced First Input Delay in March 2024 through exactly that process.
Field data and lab data
There are two ways to measure these metrics, and they answer different questions.
Field data comes from real visitors. The main public source is the Chrome UX Report, which collects measurements from Chrome users who have turned on usage statistics reporting and history sync. It is what Search Console's Core Web Vitals report and the field section of PageSpeed Insights show. Field data tells you whether there is a problem.
Lab data comes from a simulated page load in a controlled test, such as Lighthouse in Chrome DevTools. It can't measure INP directly, because no real person is interacting, so lab tools use a stand-in such as Total Blocking Time. Lab data tells you why there is a problem: which element was the LCP, which resources blocked rendering and which elements moved.
Use field data to decide what to fix, and lab data to find the cause and confirm the fix. Don't chase a lab performance score of 100 if your field data is already good.
Where to see your scores
Three free tools cover most needs:
- Search Console, Core Web Vitals report: field data for the whole site, grouped into sets of similar URLs, with a status for mobile and desktop. A group's status is its worst metric.
- PageSpeed Insights: field data for one URL or origin over the previous 28 days, plus a Lighthouse lab test with diagnostics.
- Chrome DevTools: the Performance panel and Lighthouse, for testing on your own machine with network and CPU slowed down.
Small or new sites often show "No data available". The Chrome UX Report only includes pages with enough real visits, and pages must be publicly discoverable. Until data builds up, lab tests are the best guide.
We walk through each tool, and how to read the results, in our website speed test guide.
How Core Web Vitals relate to SEO
Google says Core Web Vitals are used by its ranking systems, and it recommends that site owners achieve good scores for success with Search. It also says there is no single page experience signal. Its systems look at many aspects together, such as mobile friendliness, HTTPS and whether ads or pop-ups get in the way of the content.
Google is equally clear about the limits. Good results in Search Console or other tools don't mean a page will rank at the top, because there's more to page experience than scores alone. A fast page that doesn't answer the search won't outrank a slower page that does.
So treat Core Web Vitals as a quality floor. Fix pages that are poor, especially templates used across many URLs, then put the rest of your effort into content. The platform you build on affects how much control you have over loading, which we touch on in our post on the platforms we build on.
Core Web Vitals and accessibility
Performance and accessibility overlap, but they are not the same thing. A page can pass all three metrics and still be hard to use with a keyboard or a screen reader.
The overlap is real, though. Layout shifts make people lose their place or tap the wrong button, and that hits hardest for people using screen magnifiers or who have limited fine motor control. A sticky banner that appears late can also cover the element that has keyboard focus. WCAG 2.2 addresses that in Focus Not Obscured (Minimum), a Level AA criterion.
Some speed fixes can also create barriers. Fixing a block's height in pixels to stop a shift can break the page when text is enlarged or the screen is narrow. WCAG's Reflow criterion asks that content still works at a width of 320 CSS pixels without scrolling in two directions. And autoplaying hero video, which is often the LCP element, must have a way to pause it if it runs for more than five seconds.
The fixes for each metric are covered in how to improve Largest Contentful Paint and how to fix Cumulative Layout Shift. If you'd rather have performance and accessibility handled as part of a build, our in-house web team designs and develops sites with performance and SEO foundations built in.
Common questions
What happened to First Input Delay?
Interaction to Next Paint replaced First Input Delay as a Core Web Vital on March 12, 2024, and FID was deprecated. FID only measured the delay before the browser began handling the first interaction. INP looks at the responsiveness of interactions across the whole visit, including the time to run event handlers and paint the next frame. Older reports and articles may still mention FID.
Why is my PageSpeed Insights score different from Search Console?
They usually show different kinds of data. The performance score at the top of PageSpeed Insights comes from a single simulated Lighthouse load. Search Console's Core Web Vitals report uses field data from real Chrome users over time, grouped into similar URLs. A page can score well in the lab and still fail in the field, because real visitors use slower phones and networks.
Why does Search Console say there's no data for my site?
The report relies on the Chrome UX Report, which only includes pages and sites with enough real-user visits. New sites, new pages and low-traffic pages often fall below that threshold. A page also has to be publicly discoverable to be included. Until data appears, use lab tests such as Lighthouse, or collect your own field data with a small script on the site.
Do Core Web Vitals scores change when I fix a problem?
Lab results change straight away, so you can confirm a fix with a new test. Field results take longer. The Chrome UX Report data shown in PageSpeed Insights covers the previous 28 days, so a fix shows up gradually as new visits replace old ones. In Search Console, you can start a validation for a fixed issue and follow its progress.