Real User Data
Search Console's Core Web Vitals report reflects real visits. That is the diagnosis; a lab tool is the debugging step afterwards.
A perfect lab score means very little if real visitors are having a different experience. Core Web Vitals are measured from actual page loads, on real devices and real connections, and that is where the diagnosis has to start. We work from field data, find what is actually causing each metric to fail, and fix that — rather than optimising toward a number in a testing tool.
Lab tools run one page on one simulated device. Field data is what visitors actually experienced, and it is what the thresholds are assessed against.
Search Console's Core Web Vitals report reflects real visits. That is the diagnosis; a lab tool is the debugging step afterwards.
A number tells you there is a problem. Finding which element, which script and which request caused it is the actual work.
Google publishes what counts as good: LCP under 2.5s, INP under 200ms, CLS under 0.1, at the 75th percentile. Those are their figures, not ours.
Every change is measured, because performance work regularly fails to help and occasionally makes things worse.
We do not rebuild a working site to chase a metric. The fix has to be proportionate.
Three different experiences, with three different causes and three different fixes.
Get a Free Vitals Check →How long until the largest visible element appears. Usually a hero image, a heading, or whatever is blocking them from rendering.
How long the page takes to respond to interaction. Almost always JavaScript occupying the main thread when someone taps.
How much content moves while loading. Images without dimensions, fonts swapping, and content injected above what is already on screen.
Diagnosis from field data, then targeted fixes, then verification that they worked.
The pattern of failure usually points straight at the cause.
Where LCP is a hero image nobody optimised.
Where INP fails because hydration blocks the main thread.
Where CLS comes from injected content with no space reserved.
Large catalogues where template-level fixes affect thousands of URLs at once.
Nothing is changed before the cause is identified. Performance work done blind usually achieves nothing.
Which templates fail which metric, on which devices.
Tasks InvolvedPer template, what element and what request are responsible.
Tasks InvolvedTargeted changes, biggest lever first.
Tasks InvolvedField data re-checked, because lab gains do not always reach visitors.
Tasks Involved






Core Web Vitals are three metrics Google uses to describe page experience: Largest Contentful Paint for loading, Interaction to Next Paint for responsiveness, and Cumulative Layout Shift for visual stability.
Google publishes the thresholds: LCP under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1, assessed at the 75th percentile of page loads. Those are their figures — we do not set them and do not estimate them.
They are part of how Google assesses page experience, but they are one signal among many and relevance dominates. A fast page with the wrong content does not outrank a slower page that answers the query. Treat vitals as removing a disadvantage rather than creating an advantage.
A lab tool simulates one load on one configuration. Search Console reports what real visitors experienced across devices and networks. When they disagree, the field data is the one that counts.
Field data is reported over a rolling window, so improvements appear gradually rather than immediately even when the underlying fix worked the day it shipped. Lab testing confirms the change; field data confirms it reached people.
Still deciding if core web vitals seo is right for you?
Talk to UsSend us your site. We will read the field data, identify which page templates fail which metric, and tell you what is causing each one.
