Core Web Vitals Thresholds: LCP, INP and CLS Explained

Core Web Vitals are three Google metrics describing what using a page actually feels like: LCP (how quickly the main content appears), INP (how quickly the page answers a tap) and CLS (whether the layout jumps under your finger). Definitions are everywhere — the trouble starts when PageSpeed Insights reports one score, Search Console reports another, and you have no idea which to trust. This guide untangles that knot: where the two scores come from, what to do when your site is missing from Google’s data altogether, and what to check for each of the three metrics.

Three metrics, three thresholds and one percentile

A page passes Core Web Vitals when LCP is 2.5 seconds or less, INP is 200 milliseconds or less, and CLS is 0.1 or less. The assessment does not cover a single load but the 75th percentile of all loads, counted separately for mobile and desktop.

Only for INP does the documentation split a “needs improvement” band from a “poor” one. The 75th percentile means three quarters of loads have to fit inside the threshold — your own phone on a fast connection is not representative; the tail of slower sessions decides the result. INP replaced FID (First Input Delay) and has been a stable Core Web Vitals metric since 2024; FID is retired, so any material treating that acronym as current is out of date. None of it says whether the site can be operated with a keyboard or a screen reader — a separate area, governed by the European Accessibility Act and WCAG.

Why PageSpeed Insights shows something different from Search Console

Because they are two different kinds of measurement, not two views of one. The Lighthouse score in PageSpeed Insights is lab data: a single load of a single URL, on a simulated connection and device, under sterile conditions. The Core Web Vitals report in Google Search Console is field data from CrUX (Chrome User Experience Report): real loads by real Chrome users, aggregated at the 75th percentile over a rolling 28-day window.

Field data is what counts for Google’s assessment. Lab data is a diagnostic instrument — it tells you what to fix, not how the search engine sees the page. PageSpeed Insights shows both: the upper section is CrUX field data, the lower one a Lighthouse test run a moment ago.

What to do when your site has no CrUX data

If a site gets too little traffic, CrUX collects no data for it and no Google tool will show a field score — your own measurement is then the only route. This is the normal situation for a typical company website, and why owners get stuck on a message about insufficient data.

Your own measurement has three parts. First, the web-vitals JavaScript library wired into the site — it collects LCP, INP and CLS from your visitors and sends them to an analytics tool; feeding those events into your reporting stack is ordinary system integration work, not a separate project. Second, the Web Vitals Chrome extension, which shows live values as you click through the site by hand. Third, tests on real devices — a mid-range phone on a mobile network, not just a developer laptop on fibre.

On top of that sit lab tools with measurement history: WebPageTest, GTmetrix and DebugBear let you compare releases and catch a regression before your visitors do.

Are Core Web Vitals a ranking factor

Yes, but not in the sense the claim is usually sold. Google’s Search documentation (developers.google.com/search/docs/appearance/page-experience) states plainly: “Core Web Vitals are used by our ranking systems”. The same page adds a second sentence: “There is no single signal” — there is no one “page experience ranking system”, and Core Web Vitals results are one signal among many.

The honest conclusion is asymmetric. Good scores guarantee nothing: a page with flawless LCP, INP and CLS but weak content will not beat a better answer to the visitor’s question. Bad scores can cost you twice over — as a signal the ranking systems take into account, and as a real barrier for someone who closes the tab before the page reacts. Treat Core Web Vitals as technical hygiene, not as a ranking lever.

A separate diagnostic path for LCP, INP and CLS

Each metric breaks for a different reason, so a shared list of tips along the lines of “compress your images” does not get you far. Below is the order actually worth following.

Bad LCP

1. In PageSpeed Insights, check which element was flagged as LCP — usually the hero image, a banner or a large headline.
2. In Chrome DevTools, open the Performance panel, record a load and find the LCP marker in the Timings section: it shows the second at which that resource starts downloading.
3. In the Network tab, check whether the LCP file is queued behind stylesheets and scripts, or has lazy loading switched on by accident.
4. Judge the asset itself: format, weight, a version matched to the screen width, fetch priority.
5. Measure server response time — WebPageTest breaks it down into TTFB, transfer and rendering. If the server answers slowly, no amount of image optimisation makes up for it.

Bad INP

1. Turn on the Web Vitals Chrome extension and click through the site the way a visitor does: menu, filters, cart, form. The extension reports INP for each interaction.
2. Repeat the worst interaction while recording in the Performance panel and look for long tasks blocking the main thread.
3. Work out which script triggers those tasks. On company websites it is almost always third-party code, not your own.
4. Block the suspect scripts one by one (request blocking in the Network tab) and repeat the measurement — you will see what each tool costs.
5. In field data, check which pages have the worst INP. Forms and product search usually fare worse than the home page.

Bad CLS

1. In DevTools, switch on layout shift region highlighting — you will immediately see which blocks jump.
2. Check images, iframes and embedded players with no declared dimensions. That is the single most common cause.
3. Look at fonts: swapping a typeface after load can shift whole paragraphs.
4. List everything added to the page after it renders — the consent banner, a promo bar, the chat window, product recommendations.
5. Measure on a narrow screen. CLS is often zero on desktop while the same layout falls apart on a phone with every load.

Third-party scripts: chat, pixels and the consent banner

On a typical company website the most common cause of bad INP and CLS is not your own code but the scripts added by marketing and external tools. Each of them — an ad pixel, a map, a review widget, A/B testing, a chat window, a consent management platform — adds work on the main thread precisely when the visitor starts tapping.

The consent banner is a special case: it hits both metrics at once, pushing content down when no space is reserved for it and blocking the thread with its own script. Its layout also matters for website accessibility, because a banner that covers content and cannot be dismissed from the keyboard is a problem regardless of the CLS score.

A practical rule: every third-party script needs an owner and a justification. Once a quarter, walk the list and remove what nobody uses — tools from finished campaigns can sit in the code for years. Before adding another, check whether the same data could be pulled through an integration with a system you already run instead of injecting foreign code into the visitor’s browser.

What speed is actually worth in sales

The best documented reference point is the “Milliseconds Make Millions” study, commissioned by Google and carried out by Deloitte and the agency 55, published in 2020 on data collected in late 2019. It covered 37 European and American brands and more than 30 million sessions, with mobile timings measured over 30 days.

The retail result: a 0.1 second improvement in load time was associated with 8.4% higher conversions and 9.2% higher average order value. For travel — conversions higher by 10.1%, order value by 1.9%.

One caveat matters more than the numbers: this is a correlational study, not a causal experiment. It shows faster sessions went together with better sales outcomes — it does not prove that cutting 0.1 s will by itself lift your conversion rate by the same amount. Treat the figures as an argument for measuring performance at all, not as a forecast of return on investment.

When you will see the effect of a fix, and how to hold a supplier to it

You will not see it straight away — field data is calculated over a rolling 28-day window, so for several weeks after release the Search Console report mixes pre-fix traffic with post-fix traffic. In the days after a change, check your own measurements instead (the web-vitals library, the Web Vitals extension, lab tests) and treat the Google report as late confirmation. A sudden drop immediately after release is usually a regression signal, not noise. That same 28-day lag is what makes a rebuild risky, so plan a website migration without losing rankings with measurements taken before the switch as well as after it.

The second conclusion concerns the contract. Performance is measurable, so it belongs in the written acceptance criteria — scope that was never described comes back as the cost of post-launch fixes, through exactly the mechanism that drives mobile app development cost or the price of rebuilding a store. Put the Core Web Vitals requirement into the document that starts the conversation with a supplier: the brief for a software project.

At some point patching an old site stops paying off and the question turns into WordPress or a custom website, because a theme and its plugins set a performance ceiling your own template does not. For a shop the same question takes a different shape: a hosted or a custom online store decides how much of the template, the scripts and the URLs you are allowed to touch at all.

If you are planning a new site or a rebuild rather than repairing an existing one, set the performance requirement before design starts and talk the scope through with us — a threshold agreed up front costs far less than one renegotiated after handover.