The short version
- Field data is real users. Lab data is a simulation. Only field data reflects what people actually experienced.
- The three metrics are LCP, INP and CLS — loading, responsiveness and visual stability.
- Field data is reported at the 75th percentile, so a quarter of your users can be having a worse time than the number suggests.
- Use lab data to find the cause; use field data to decide whether there is a problem at all.
Core Web Vitals generate a lot of anxious optimisation, much of it aimed at a number that does not affect anything. The distinction between the two kinds of data is what separates useful work from score-chasing.
Field data comes from real Chrome users who visited your site — their devices, their networks, their circumstances. Lab data comes from one simulated load under controlled conditions. Field data is the input that matters; lab data is how you find out why.
The three metrics
CLS is usually the cheapest to fix and the most annoying to users. Setting explicit width and height on images, and reserving space for anything injected after load, resolves most of it — and it is a template change rather than an architectural one.
The 75th percentile
Field data is assessed at the 75th percentile, meaning 75% of visits were at least as good as the reported figure. That is a deliberately demanding standard: passing means most users had an acceptable experience, and a quarter of them may still not have.
It also explains why averages mislead here. A site can have a good average LCP and fail the assessment because a subset of users — older devices, slower networks, a particular template — are having a substantially worse time. Segment by page group in Search Console rather than looking at one figure for the whole origin.
How much does it actually matter for rankings?
Core Web Vitals are a real but modest factor, best understood as a tiebreaker between comparably relevant pages rather than a primary driver. A page that is the best answer will generally outrank a faster page that is not.
That does not make performance unimportant — it affects conversion, bounce and how much of your content people actually read, all of which matter independently of rankings. It means the right target is "not bad" rather than "perfect". See where effort pays.
Fix at the template level
Core Web Vitals reporting groups URLs, and that grouping is a hint about where the fix belongs. When a group of pages fails together, they almost always share a template — and the cause is one decision in that template rather than a hundred individual page problems.
That reframes the work usefully. Instead of a list of failing URLs, you have two or three templates with a specific defect each: an unoptimised hero image, a third-party script blocking the main thread, a font loading strategy causing layout shift. Each is one change affecting every page that uses it. Teams that work URL by URL through a vitals report rarely finish; teams that group by template usually do it in a sprint.
Third-party scripts deserve their own review in that process. Analytics, tag managers, chat widgets, consent banners and advertising tags accumulate over years, are rarely removed, and collectively dominate main-thread work on many sites. Auditing what is loading and why — and removing anything nobody can name an owner for — is frequently the single largest available improvement, and it requires no changes to your own code at all.
The practical sequence
Check the Core Web Vitals report in Search Console, which groups URLs and shows field data at scale. If a group fails, take one URL from it into PageSpeed Insights and use the lab diagnostics to find the cause. Fix at the template level, because a group failing means a template is failing.