Core Web Vitals: what LCP, INP and CLS are, their thresholds and how to improve them

Core Web Vitals are the three metrics Google uses to measure a page's experience: LCP (how fast the main content loads), INP (response to clicks, taps and key presses) and CLS (visual stability). A page passes if, at the 75th percentile of visits, LCP is 2.5 s or less, INP 200 ms or less and CLS 0.1 or less.

To check it on your own site: SEO audit

They are the measurable side of speed within SEO, and almost every audit tool reports them. This guide explains what each one measures, where the data comes from and how to diagnose and fix each metric. If you run an online shop, the problems specific to product and category pages are covered in Core Web Vitals for e-commerce.

What are Core Web Vitals?

Core Web Vitals are the subset of Google's Web Vitals that applies to all web pages and covers loading, interactivity and visual stability. All three current metrics are "stable", and Google commits to changing a stable metric no more than once a year, with the change announced in its documentation1.

One such change has already happened. INP replaced FID (First Input Delay) as a Core Web Vital on 12 March 20242. FID only measured the delay before the first interaction was handled; INP observes every interaction during the visit. If a tool or an article still talks about FID, its data or its advice predates that change.

What are the official thresholds?

Google sets a "good" limit for each metric and another beyond which the result is "poor"; in between sits "needs improvement". The thresholds are the same in PageSpeed Insights and Search Console34:

What gets compared with those limits is not the average but the 75th percentile of page loads, segmented by mobile and desktop1. In other words, a metric passes if at least three out of four visits have a good experience. That is why a page can feel fast on your desktop on fibre and fail on your visitors' phones.

PageSpeed Insights marks the assessment as passed when the 75th percentile of all three metrics is "good". If there is not enough INP data, good LCP and CLS are enough; if LCP or CLS data is missing, there is no assessment3.

Field data versus lab data

There are two ways of measuring the same metrics, and most confusion about Core Web Vitals comes from mixing them up.

Three details about CrUX explain results that puzzle people:

• Only Chrome on desktop and Android counts. Chrome on iOS and other Chromium-based browsers do not contribute data5. If most of your traffic comes from iPhones, the field data describes a minority of your visits.
• A minimum number of visitors is required, which Google does not disclose, and the page has to be public and indexable5. If a URL falls short, PageSpeed Insights shows data for the whole origin; if the origin falls short too, there is no field data3.
• Changes take time to show. Because it is a 28-day window, a fix published today will not be fully reflected for four weeks.

It is normal for lab and field data to disagree. Web.dev lists the reasons: caching, each user's device and network, personalised content or A/B tests that change the LCP element, and pages restored instantly from the browser's back/forward cache6. Its advice is to prioritise using field data6. How to read each part of the report is covered in the guide to PageSpeed Insights.

LCP: how to diagnose and improve it

LCP is the time from when the user opens the page until the largest image, video or text block in the first screen is rendered7. Candidates include img elements, video poster images, background images loaded with CSS url() and block-level text7.

The first step is knowing which element it is. Lighthouse tells you, and breaks it down into four parts. Web.dev suggests a rough split for a well-optimised page8:

Whichever part strays from that split tells you where to work:

• High load delay: the image is discovered late. Typical causes are loading="lazy" on the main image (web.dev says never to do this) or an image that only appears once JavaScript runs. Mark that image with fetchpriority="high"8.
• High load duration: the image is too heavy. Compress it, use modern formats and serve the right size for each screen; the details are in the guide to image SEO.
• High TTFB: chained redirects or a slow server; page caching and a CDN help8.
• High render delay: stylesheets and scripts that block rendering8.

INP: how to diagnose and improve it

INP measures the latency of every click, tap and key press during a visit and reports a single value that all, or nearly all, interactions were below9. Hovering, scrolling and zooming do not count9.

Every interaction has three phases: input delay (the browser is busy and cannot handle the click yet), processing duration (how long your code takes to react) and presentation delay (how long the result takes to be painted)9.

INP is the hardest metric to diagnose, because it depends on what each user does. Web.dev suggests an order: identify slow interactions in the field data, reproduce them in the lab and optimise whichever phase takes longest10. To reproduce them, the Performance panel in Chrome DevTools shows live LCP, CLS and INP for your own interactions, and can compare them with CrUX field data11.

The usual fixes, by phase10:

• Input delay: less JavaScript running while the page loads, especially third-party code (chat, advertising, analytics).
• Processing: do only what is essential to show the response in the event handler, and yield to the browser between chunks of work.
• Presentation: a smaller DOM and less HTML generated in the browser with JavaScript.

CLS: how to diagnose and improve it

CLS measures the largest burst of unexpected layout shifts during the entire life of the page12. A burst groups shifts that happen less than a second apart, up to a maximum of five seconds. Shifts within 500 ms of a click or key press do not count, because the user expects them12.

Lighthouse points out which elements moved. The causes and fixes are almost always the same13:

How much do Core Web Vitals matter for rankings?

Google is explicit: Core Web Vitals are used by its ranking systems, and it recommends achieving good Core Web Vitals14. On the same page it adds two caveats that put them in context14:

• Google Search always seeks to show the most relevant content, even if the page experience is sub-par.
• Getting good results in Search Console's report or in third-party tools does not guarantee that your pages will rank at the top.

In practice, a page that answers the search better beats a faster page that answers it worse. Core Web Vitals matter when several pages are equally useful, and they always matter to your visitors' experience. That is why they are best reviewed as part of an SEO audit rather than as an end in themselves.

How SmoothSeen checks them

Declaration of interest: this blog belongs to SmoothSeen, a web audit tool that measures visibility in search engines and AI assistants. Its report takes speed from PageSpeed Insights, both field data and lab data, so what you see in it matches what you see in PageSpeed. It combines that with the rest of the search visibility checks and compares it with up to three competitors. It analyses one page at a time and does not connect to Search Console.

Frequently asked questions

What is a good LCP score?

An LCP of 2.5 seconds or less at the 75th percentile of visits, measured separately for mobile and desktop. Between 2.5 and 4 seconds needs improvement, and over 4 seconds is poor. What counts is field data from real users; the LCP from a lab test helps you find the cause, not decide whether you pass.

What happened to FID?

Google retired it as a Core Web Vital on 12 March 2024 and replaced it with INP. FID only measured how long the browser took to start handling the first interaction; INP measures every interaction during the visit, from start to finish, until the response is painted. Search Console stopped showing FID that same day, and other tools removed it over the following months.

Why does my site have no Core Web Vitals data?

Because CrUX only includes public, indexable pages with a minimum number of visitors, which Google does not disclose, and it only collects data from Chrome on desktop and Android. If your URL falls short, PageSpeed Insights shows data for the whole domain; if the domain falls short too, you will only see lab data. Work with that meanwhile, and review templates rather than individual pages.

Can I pass Core Web Vitals with a low performance score?

Yes. The 0 to 100 score in PageSpeed Insights comes only from the lab test and blends in metrics that are not Core Web Vitals, such as Total Blocking Time. The Core Web Vitals assessment comes from field data. A page whose visitors use good devices and connections can pass with a mediocre lab score, and the reverse can happen too.

What to do next

Run your most important page through PageSpeed Insights, check in the field data which metric is not "good" and apply the fixes in its section. Then carry on with the guide to what SEO is to see where speed fits in the rest of the work.