Core Web Vitals in Practice

Two kinds of data, and only one of them is the assessment

Nearly every argument about site speed is really an argument between two data sources that were never measuring the same thing.

Lab data comes from a synthetic test: one load, one URL, one simulated device and network, run on demand. It is reproducible, immediate, and ideal for debugging — you change something, you re-run it, you see whether the change did what you intended.

Field data is collected from real visits by real people on real devices and connections, accumulated over a period. It is what Core Web Vitals assessment is based on. It moves slowly, it cannot be produced on demand, and it is the one that describes your business.

They disagree constantly, and the disagreement is not a malfunction. Your lab test ran on a fast connection from a data center; your customers are on four-year-old phones on hotel wifi. When a developer says the page is fast and the report says it is not, both can be telling the truth about the data in front of them. The rule to settle it: field data decides whether there is a problem; lab data helps you find and fix it.

What the 75th percentile actually asks of you

All three metrics are assessed at the 75th percentile of page loads, segmented by mobile and desktop. Both halves of that change the work.

The percentile means the target is not the typical visit. It is the visit at the three-quarter mark of your distribution, ordered worst to best — so you are optimizing for the slower quarter of your audience, which is exactly the group an average conceals. A page can have a good median and fail, and the fix will be found among your slowest cohorts: older devices, weaker networks, and whatever third-party code only executes for some visitors.

The device segmentation means mobile and desktop are two separate assessments of two separate populations. Passing on desktop while failing on mobile is failing, for most sites on the traffic that matters. Read them as two reports and resist the temptation to average them into a single reassuring figure.

One more property of field data trips teams up: it accumulates from visits over time, so it lags deploys and improves gradually. That is a reason to be patient after a fix, not a reason to switch back to the lab score because it responds faster.

Largest Contentful Paint: did the main thing appear

LCP measures loading, and the threshold for good is 2.5 seconds or under at the 75th percentile.

What it reports is the render time of the largest content element visible in the viewport — in practice a hero image, a video poster, or a large block of text. So the diagnostic question is not "why is the page slow" but the far narrower "what is the largest element on this template, and what is standing between the request and its appearance?"

The recurring answers in my experience are unexciting and repeatable: an oversized image served at desktop dimensions to phones, a headline waiting on a web font that loads late, a server that takes too long to respond before anything can begin, and render-blocking resources sequenced ahead of the content people came for. Server response time and HTTP caching also carry a second benefit worth citing internally: Google's crawl guidance states that if it can load and render your pages faster, it might be able to read more content from your site, and it recommends supporting 304 Not Modified so cached versions can be reused.

Fix by template, not by URL. Almost nobody has a slow page; they have a slow page type rendered across thousands of URLs, and the tool happened to test one of them.

Interaction to Next Paint: what it counts, and what it ignores

INP measures responsiveness. Good is 200 milliseconds or under, and above 500 milliseconds is poor.

First, the vocabulary correction, because it still appears in circulating audits: First Input Delay is not the current metric. INP was promoted from experimental in 2023 with the stated intent of eventually retiring FID, and became a stable Core Web Vital in 2024, replacing it. A report presenting FID as current was written against a superseded standard.

Now the part that surprises everyone. INP counts exactly three interaction types: clicking with a mouse, tapping a touchscreen, and pressing a key, physical or onscreen. Scrolling, hovering and zooming are excluded. A page that feels janky while scrolling can post a perfectly good INP, and that gap deserves naming in a report rather than being explained away later.

What it measures is the full round trip: the time from the start of the interaction to the moment the next frame is fully presented. That is input delay plus event handler processing plus rendering — not merely the delay before your code runs. A handler that finishes quickly but triggers an expensive re-render still produces a poor score.

For most pages, the worst interaction is what gets reported. On high-interaction pages an outlier rule discards one interaction per fifty. The practical consequence is that a single slow control — a filter, an accordion, an add-to-cart that revalidates the page — can define the metric for a template where everything else is fine. Find that control before optimizing anything general.

Cumulative Layout Shift: bursts, not sums

CLS measures visual stability. Good is 0.1 or under; above 0.25 is poor.

It is widely misunderstood as a running total of everything that moved on the page. It is not. Shifts are grouped into a burst when the gap between individual shifts is under one second, with a maximum window duration of five seconds, and the reported CLS is the largest such burst rather than the sum of all shifts.

That definition tells you where to look. One bad moment dominates the score: an ad slot resolving without reserved space, a cookie banner injected above the content, an image without declared dimensions, a font swap that reflows a heading, a component that expands after data arrives. Scattered small movements across a long session matter far less than a single cluster at the moment the page settles.

The fixes are mostly about reserving space in advance rather than making anything faster — explicit dimensions on images and embeds, reserved containers for anything injected asynchronously, overlays that composite rather than push content down. CLS is usually the cheapest of the three to fix and the most obviously irritating to leave broken, which makes it a good first win when you need internal support for the rest of the work.

Reading the report without over-reacting

Three habits prevent most bad decisions taken from a performance report.

Group by template before reacting. A list of failing URLs is a list of instances of a small number of failing page types. Group them, put traffic and revenue against each group, and work the list in commercial order rather than by worst score.

Do not chase small movements. Field data is aggregated from real visits, so it fluctuates with your traffic mix as much as with your code. A metric that crosses a threshold and crosses back has not told you anything actionable. Look at the shape over a longer window and at whether a specific deploy aligns with a specific change.

Check whether the failure is even yours. Third-party scripts — tag managers, chat widgets, personalization, ad code, consent tools — frequently dominate both INP and CLS. Inventory what loads and what each tag is for before proposing engineering work on your own code. That inventory is often the highest-value hour in the whole exercise, and the conversation it starts is political rather than technical.

What passing does and does not buy

Be precise about this internally, because overstating it is how a whole program loses credibility.

What passing gets you: visitors who do not leave because the page was unusable, forms that respond when tapped, and a site that does not move under someone's thumb. On transactional templates that is a commercial argument on its own, measurable in your own conversion data without reference to search at all.

What it does not get you: a promised ranking movement. Nobody outside Google operates the ranking system, and Google states plainly that there is no guarantee that changes you make to your site will result in noticeable impact in search results. Sell speed work on the visitor argument and the documented crawling argument, and let any ranking benefit be an unquantified bonus.

And keep it in sequence. Performance sits downstream of whether pages can be reached, rendered and stored. A perfectly fast page that is blocked, carries a stray noindex, or answers a question nobody asks earns nothing. Speed is table stakes, not a strategy.

A working routine

The loop that actually improves things is short and repeats.

1. Baseline. Record field numbers at the 75th percentile, split by mobile and desktop, grouped by template, with traffic and revenue attached. Date the file.
2. Pick one metric on one template. The one carrying the most revenue, not the one with the worst number.
3. Diagnose in the lab. This is where synthetic tools earn their place: reproduce, isolate, identify the specific element or script.
4. Ship one change. Batched changes make attribution impossible and the next investigation harder.
5. Verify twice. Immediately in the lab to confirm the change did what was intended; later in the field to confirm real visitors experienced it.
6. Stop when the template passes on both device classes, and move to the next one. Beyond the good threshold, engineering cost rises and returns fall.

The definitions above come from Google's own documentation, and it is worth reading them at source rather than through summaries — particularly the INP article and the CLS article, both of which contain mechanical detail that changes what you would prioritize.

Frequently Asked Questions

Published 2026-08-11