Core Web Vitals: the 3 thresholds and where to start

The Core Web Vitals come down to three numbers: a Largest Contentful Paint under 2.5 seconds, an Interaction to Next Paint under 200 milliseconds and a Cumulative Layout Shift under 0.1. Three conditions come with them, and they are what separates a site that passes from a site that thinks it passes: the measurement is taken from your real users’ visits, it keeps the 75th percentile of those visits, and it assesses mobile and desktop separately.

In other words, it is not enough for the page to be fast on your machine. It has to be fast for three visitors out of four, on their phone, on their connection. This article explains what each metric measures, why the score you see in your browser means almost nothing, and in what order to fix things.

The three thresholds, and what they actually measure

Google publishes these three metrics under the name Web Vitals. They cover three distinct dimensions of the experience: display speed, responsiveness and visual stability. A site can excel at one and fail the other two.

LCP: how long the largest element takes to appear

The Largest Contentful Paint measures the moment the largest visible element of the page appears on screen. In practice that is almost always the hero image, the cover video or the large heading block. The threshold is 2.5 seconds.

What this metric captures is the question the visitor is asking while the page loads: has anything useful arrived yet? A site that shows a white background for four seconds and then everything at once has a poor LCP, even if the total time matches a site that renders progressively.

INP: responsiveness when someone clicks

The Interaction to Next Paint measures the delay between a user action and the moment the screen updates in response. It replaced First Input Delay in March 2024, and it is stricter: where the previous metric only measured the first click, this one observes every interaction in the visit. The threshold is 200 milliseconds.

The documentation breaks each interaction into three phases: the input delay before your code runs, the processing duration of the callbacks it triggers, and the presentation delay before the next frame is painted. Knowing which of the three dominates changes the fix entirely.

CLS: visual stability

The Cumulative Layout Shift measures unexpected movements of the layout during loading. The threshold is 0.1, and the calculation is worth knowing: it is not the sum of every shift but the largest burst. A burst groups shifts separated by less than one second, within a window of five seconds at most.

Shifts caused by a user action do not count, provided they happen within 500 milliseconds of the interaction. Opening a dropdown menu will not hurt your score. A consent banner that inserts itself after two seconds will.

The number one trap: your browser score is not your grade

This is the most common confusion, and it costs weeks. The Lighthouse tool built into Chrome, like the left-hand panel of PageSpeed Insights, produces what is called a lab measurement: a simulation, on a simulated machine and connection, at one point in time. The score out of 100 it returns is not your Core Web Vitals result.

What counts is the field measurement, taken from the Chrome UX Report, which aggregates real visits from Chrome users who opted into usage statistics. That is the source used by Search Console and by the top panel of PageSpeed Insights. Three practical consequences follow.

• The data is a rolling 28-day window. A fix deployed today takes roughly four weeks to be fully reflected. Do not judge a fix after three days.
• A low-traffic site may have no data at all. The report requires enough visits to be statistically significant. Below that, Search Console stays empty and you fall back on lab measurement, knowing it is only indicative.
• The 75th percentile allows 25% of bad visits. The threshold is met as soon as three visits out of four are good. Google documents that choice in its note on how the thresholds were defined: it is a compromise between rigour and realism.

Three tools, three uses

Search Console gives the field truth, grouped by page template: that is where you decide what to fix. PageSpeed Insights combines both measurements on a single URL, with field data at the top and the simulation below: that is where you understand why. The Web Vitals extension for Chrome shows the three metrics live as you browse: that is where you verify a fix before deploying it, without waiting four weeks.

Where to start, concretely

The order that saves the most time is to handle whichever metric fails on mobile first, then break it down before fixing anything. Fixing without breaking down is optimising at random.

Break LCP into four segments

The LCP optimisation guide splits the delay into four parts, with a target distribution. Server response time, or TTFB, should account for roughly 40% of the total. The delay before the browser starts loading the resource, under 10%. Loading the resource itself, around 40%. The final render delay, under 10%.

That grid names the culprit in a minute. A TTFB weighing 70% points at hosting, the database or caching, and that is where a CDN changes things. A dominant resource load duration points at the weight of the hero image, a subject we cover in our article on reducing image weight. A high render delay points at a custom font blocking display, or a component waiting on JavaScript before painting.

Three fixes cover most cases: never lazy-load the hero image, serve it as WebP or AVIF at the right dimensions, and preload the resource identified as the LCP element.

Place INP within its three phases

A degraded INP almost always comes from the same place: too much JavaScript running on the main thread at the moment the user clicks. The INP optimisation guide recommends breaking up long tasks, deferring anything not needed for the immediate interaction, and yielding to the browser so it can paint.

On a brochure site, the first suspect is not your own code but third-party scripts: tag manager, chat widget, A/B testing, advertising pixels. The decisive test is to reload the page without them and compare. If INP collapses, the discussion becomes one about marketing priorities, not about engineering.

Track down the three causes of CLS

The CLS guide reduces the essentials to three causes. Images and videos with no declared dimensions, which push content down as they arrive: setting width and height attributes is enough to reserve the space. Content injected above existing content, banners and notices, which need reserved space or should be displayed as an overlay. And custom fonts that cause a typographic jump when they load.

CLS is the cheapest metric to fix and the most visible one. On a checkout flow, a button that moves at the exact moment of the click does not just degrade a score: it costs orders, as we explain in our article on increasing your conversion rate.

The particular case of no-code sites

A hosted platform such as Webflow or Framer handles part of the work without you lifting a finger: content delivery network, response compression, images served in several sizes, certificate and caching. On paper the technical foundation is sound, and that is a genuine head start, which we detail in our article on the Webflow CMS.

What the platform does not do for you comes down to four things, and they are exactly the ones that make Core Web Vitals fail. The weight of the visuals you upload, because no tool resizes a 4,000-pixel-wide photo that you display at 800. The number of custom fonts and weights, each one a file to download before text renders properly. Third-party scripts added in the project settings, which weigh directly on INP. And scroll animations, appealing in a demo, expensive when they run during loading.

Three rules are enough to hold the thresholds on this kind of site: resize images before uploading rather than after, stick to two font weights, and keep a list of third-party scripts with, next to each one, the person who asked for it. That last column is the most useful one on the day you have to arbitrate.

What Core Web Vitals will not do for you

An honest clarification saves a lot of disappointment. Google writes in its Search documentation that good Core Web Vitals, along with other page experience aspects, “aligns with what our core ranking systems seek to reward”. The wording is careful, and it should be taken literally.

Concretely: going from red to green will not lift a page whose content does not answer the query. On the other hand, at comparable relevance, page experience is what separates results. And above all, the most measurable effect is not on ranking but on behaviour: fewer abandonments before render, more pages per session, a funnel that gets completed.

So treat these three thresholds as a quality criterion you can hold a supplier to, not as a search lever. That is in fact their best use: writing them into a brief, where they beat the adjective “fast” hands down.

A five-step method

• Start from Search Console, not a third-party tool. The Core Web Vitals report groups your URLs by similarity and separates mobile from desktop. It is the authoritative source.
• Handle mobile first. It is almost always the one that fails, and it is also the version Google uses to index your pages.
• Break down before fixing. The four segments of LCP, the three phases of INP, the largest burst of shifts for CLS.
• Fix one group of URLs at a time. Pages built on the same template share their defects. Fixing the template fixes hundreds of pages.
• Wait four weeks before concluding. The rolling 28-day window imposes that delay. In the meantime, lab measurement tells you whether the fix does what you expect.

What we do with this at Scroll

We write these three thresholds into briefs, and we check them on acceptance using a real phone rather than a development machine. It is a point we cover in our articles on website redesign and on improving an existing site.

If your metrics are red and you do not know where to start, the diagnosis usually takes half a day: identify the offending template, break down the failing metric, and produce a list of fixes ranked by gain. Let’s talk.