Core Web Vitals & Site Speed

Fix what real visitors experience, not what a test tool reports

Core Web Vitals are measured on your actual visitors, on their actual devices. A perfect score in a lab tool means very little if field data says otherwise. Speed is a modest ranking factor and a substantial conversion factor, and we work on it for the second reason.

Book a Strategy Call See how we work

Definitions that matter

Three metrics, three different complaints

Core Web Vitals are not an abstract scoring system. Each of the three metrics corresponds to a specific thing people complain about, which is why they are worth taking seriously even setting search aside entirely.

Largest Contentful Paint answers "how long until the page looked loaded". It measures when the largest element in the viewport finished rendering — typically a hero image, a heading or a block of body text. It is dominated by how quickly the server responds and how early the browser discovers that one important resource.

Interaction to Next Paint answers "did it respond when I tapped". It measures the delay between a user’s interaction and the next visual update, assessed across the whole visit rather than just the first interaction. This is where sites with heavy JavaScript get caught: the page can load quickly and then feel unusable, because every tap queues behind work on the main thread.

Cumulative Layout Shift answers "why did it move while I was reading". It measures unexpected movement of visible content — images without dimensions, fonts swapping, banners injected above content, and consent dialogues that push the page down just as somebody reaches for a link.

The published thresholds

What counts as good, and how it is assessed

These are Google’s published thresholds and measurement rules, not our interpretation of them. Every figure links to the official documentation.

2.5s

Largest Contentful Paint at or below this is rated good

Source: web.dev: Largest Contentful Paint

200ms

Interaction to Next Paint at or below this is rated good

Source: web.dev: Interaction to Next Paint

0.1

Cumulative Layout Shift at or below this is rated good

Source: web.dev: Cumulative Layout Shift

75th percentile

The point in your real page loads at which each threshold is assessed

Source: web.dev: Web Vitals

28 days

Rolling window over which the Chrome UX Report aggregates field data

Source: Chrome UX Report documentation

Two details do most of the work here. The first is the 75th percentile: you are not assessed on your average visitor, you are assessed at a point where three quarters of visits are faster and a quarter are slower. Averages hide exactly the visitors this is designed to protect.

The second is the 28-day rolling window. A fix deployed today will not be fully visible in Search Console for roughly a month, which is why we implement your own real-user measurement rather than waiting on aggregated reporting to confirm whether the work succeeded.

The distinction everything rests on

Field data and lab data answer different questions

Almost every argument about site speed comes from confusing these two. One tells you what your visitors experienced. The other tells you why.

Field data versus lab data: what each is for and where each misleads
Dimension	Field data (real users)	Lab data (synthetic tests)
What it is	Measurements collected from real visits on real devices and networks	A simulated load on a specified device profile and throttled connection
Where it comes from	The Chrome UX Report, and your own real-user measurement if you have it	Lighthouse, PageSpeed Insights lab section, WebPageTest and similar
Best used for	Deciding whether a real problem exists and who it affects	Diagnosing the cause, with a trace you can actually follow
Blind spot	Tells you what happened, not why, and lags behind deployments	Cannot represent your actual audience, their devices or their networks
INP coverage	Captures real interactions across the whole visit	Cannot measure it properly — synthetic runs do not interact like people
When they disagree	This is the one that reflects your business	Treat it as a hypothesis generator, not as a verdict

The work

What performance work actually consists of

Work is prioritised by template rather than by URL. Ten thousand failing product pages are one problem with one fix, and treating them as ten thousand problems is how these projects stall.

Field data assessment by template, device class and country, so the work targets the visitors who are actually affected
LCP element identification per template, then fixing what delays it — server response, render-blocking resources, late-discovered images, font loading
INP diagnosis through long-task profiling, event handler cost, hydration behaviour and third-party script execution
Layout stability work — explicit dimensions on media, font loading strategy, reserved space for anything injected after load
Third-party tag audit with a measured main-thread cost for each tag and a recommendation on each
Image strategy — formats, responsive sizes, priority hints and what genuinely needs to load eagerly
JavaScript reduction, because the most reliable way to make a page interactive faster is to ship less of it
Real-user measurement implemented in your own analytics so you can see effects within days
A written performance budget, plus the governance rule for who can spend against it

The part nobody plans for

Why performance work usually gets undone

The technical fixes are the straightforward half. Sites regress because of how organisations work, not because the engineering was wrong.

Two teams, one page, no shared budget.: Engineering optimises the build. Marketing adds tags through a tag manager without a review step. Neither sees the combined effect until field data moves a month later, by which point nobody can identify which change caused it. A performance budget with a named owner is the only durable fix.
The team optimised for the score.: Effort goes into the parts of a lab score that are cheap to move rather than the parts users feel. You end up with a better number and an unchanged experience, and the field data does not move, which then undermines confidence in doing the work at all.
A new component ships without a budget check.: A carousel, a chat widget, a review embed, a personalisation script. Each is individually defensible and collectively they are the reason the site is slow. Without a rule requiring a measured cost before adding one, the outcome is predictable.
Nobody is measuring in real time.: Relying entirely on Search Console means a 28-day lag between a deployment and any signal about whether it helped. Teams cannot learn on that cycle, so they stop trying. Real-user measurement in your own analytics shortens the loop to days.

Questions

Straight answers about speed and Core Web Vitals

What are LCP, INP and CLS actually measuring?

Largest Contentful Paint measures when the largest visible element in the viewport finishes rendering — usually the hero image, a heading or a block of text. It is a proxy for "when did this page look loaded".

Interaction to Next Paint measures how quickly the page visually responds to a user’s interactions, taken across the whole visit rather than only the first one. Cumulative Layout Shift measures how much visible content moves around unexpectedly while the page is loading.

Between them they cover the three complaints people actually have: it took too long to appear, it did not respond when I tapped, and it moved while I was reading it.

What is the difference between field data and lab data?

Field data is collected from real visits by real people on their own devices and connections. The Chrome UX Report aggregates that data, and it is what Google uses when reporting Core Web Vitals in Search Console.

Lab data comes from a synthetic test run on a simulated device with simulated network conditions — what Lighthouse and most speed tools produce. Lab data is excellent for diagnosis because it is repeatable and gives you a trace to work from. It is not a measure of what your audience experiences.

When they disagree, believe the field data and use the lab tools to find out why.

We have a Lighthouse score of 98. Do we still need this?

Possibly not, but check the field data before concluding that. A high lab score on a fast simulated connection tells you the page can be fast. It does not tell you whether it is fast for a visitor on a three-year-old Android phone on a busy mobile network.

The score is also a weighted composite, which means it can stay high while one metric your audience actually feels — usually INP — sits in the failing range.

How much does site speed affect rankings?

Less than most people selling speed optimisation imply. Google has been consistent that page experience signals are one input among many and that genuinely useful content generally outranks faster but less relevant content.

The stronger commercial argument is conversion and cost. Slow pages lose visitors before they see anything, and on paid traffic you have already bought those visitors. That is the reason we treat performance as commercial work rather than as a ranking tactic.

Our tag manager is the problem. What do we do about it?

Measure each tag rather than arguing about them in the abstract. Most sites carry tags for tools nobody uses any more, and the cost of each one on main-thread time can be quantified.

After that it is a governance question: who approves a new tag, what evidence is required, and what the performance budget is. Without that, the tags come back within two quarters and the work is undone.

How long before improvements show in Search Console?

The underlying field data is aggregated over a rolling 28-day window, so a change deployed today will not be fully reflected for roughly a month even if it worked immediately.

Your own real-user measurement will show the change within days, which is one of the main reasons to implement it rather than waiting on third-party reporting to tell you whether the work succeeded.

Find out whether your speed problem is real

We will look at your field data by template and tell you which metric is genuinely failing, which visitors it affects and what it would take to fix. Sometimes the answer is that your lab score is misleading you and the site is fine.

Book a Strategy Call

Where to go next

Last updated September 7, 2026 · Reviewed by Zubair Afzal