There’s a particular kind of relief that comes when a site turns green on PageSpeed Insights. Scores in the eighties and nineties, all thresholds passed, a client-ready screenshot ready to go. It feels like the job is done.
But while a passing Core Web Vitals score tells you that a page hit a set of predefined thresholds under specific conditions, it doesn’t tell you whether users are having a good experience. It doesn’t tell you whether the site feels fast. And it absolutely doesn’t tell you whether the fixes you made actually mattered to real people.
These distinctions sound pedantic until you’ve spent weeks optimising a score that barely moved the needle on conversions, or watched a “passing” site haemorrhage users on mid-range Android devices.
Understanding what the scores actually measure—and where they stop being useful—is the difference between doing performance work and doing performance theatre.
What Each Core Web Vital Actually Measures
- Largest Contentful Paint (LCP)
LCP measures how long it takes for the largest visible element in the viewport to render. That’s usually a hero image, a large heading, or a video thumbnail. The threshold is 2.5 seconds for “good.”
What it doesn’t tell you: whether the content that loaded was actually useful, or whether everything below the fold is broken.
A page can score well on LCP while the rest of the layout loads chaotically beneath it. Read more about it here.
- Interaction to Next Paint (INP)
INP replaced First Input Delay (FID) in March 2024 and is a more comprehensive measure of interactivity.
Where FID only captured the first interaction, INP tracks the latency of all interactions throughout the page lifecycle—clicks, taps, key presses—and reports the worst-case response time.
This makes INP harder to game and more representative of the actual feel. A site with a sluggish dropdown or an autocomplete that hesitates will surface that in INP, even if FID looked fine. Read more about INP here.
- Cumulative Layout Shift (CLS)
CLS measures visual stability—how much the page layout shifts unexpectedly during load. A score below 0.1 is “good.”
The classic culprit is images without defined dimensions, but ads loading late, fonts swapping, and dynamic content injection all contribute.
CLS is arguably the most user-visible of the three metrics. A page that rearranges under your finger while you’re trying to tap something is immediately frustrating in a way that a slow LCP often isn’t. Read more about CLS here.
Lab Data vs Field Data: Why the Gap Matters
- The Difference Between Synthetic and Real
Lab data is collected in a controlled environment; tools like Lighthouse or WebPageTest simulate a page load on defined hardware with defined network conditions.
Field data, captured through the Chrome User Experience Report (CrUX), reflects what real users actually experienced.
The gap between the two is frequently significant. Google’s own research shows that lab and field scores often diverge, particularly on mobile, because lab tests can’t account for device variability, concurrent processes, or real-world network conditions.
- Why This Changes Everything
An agency that reports only Lighthouse scores is reporting lab data. That’s useful for identifying issues, but it’s not evidence of user experience.
A site can pass every lab test and still deliver a frustrating experience to users on a three-year-old phone in a city with patchy 4G.
Field data is the ground truth. If CrUX shows poor INP across a meaningful segment of users, that’s a real problem—regardless of what Lighthouse says.
Any credible CWV audit needs to report both, explain the delta, and prioritise fixes against field data, not lab data.
The Fixes That Move Scores Without Improving Experience
- Score Optimisation vs Experience Optimisation
Some CWV fixes are genuinely impactful. Preloading the LCP image, eliminating render-blocking resources, and reserving space for images and ads all make pages feel faster and score better simultaneously.
Others are primarily score optimisations. Deferring offscreen images improves LCP and reduces initial payload, but if those images are just below the fold, users will perceive a pop-in effect that feels worse.
Aggressively lazy-loading content can tank perceived performance even as it flatters the metrics.
- The Lighthouse Trap
Lighthouse scores are calculated on a specific simulated page load. A developer who knows how the scoring works can make targeted changes that disproportionately improve the score without materially changing what users experience.
This isn’t necessarily cynical—sometimes it happens by accident—but the result is the same: a better number that doesn’t reflect a better experience.
A 2023 analysis by Treo found meaningful gaps between lab and field performance data across a broad sample of sites, underscoring why score-focused optimisation without field validation can be misleading.
The audit report that only shows before-and-after Lighthouse scores is telling an incomplete story.
How to Prioritise Core Web Vitals Fixes by Impact
- Start With Field Data Segmentation
Before prioritising any fix, segment the CrUX data; overall scores mask significant variation.
A site might have “good” LCP on desktop and “poor” LCP on mobile. Certain pages—high-traffic landing pages, checkout flows, article templates—may be dragging down the overall score while the rest of the site is fine.
Prioritise by traffic volume multiplied by severity. A “needs improvement” score on a page that accounts for 40% of sessions matters far more than a “poor” score on a page that gets 200 visits a month.
- Fix the Cause, Not the Symptom
- For LCP: Identify the actual LCP element on real devices, not just in DevTools. Ensure it’s preloaded, served from an appropriate CDN, and not behind a client-side render. Check that the resource is discoverable in the initial HTML, not injected by JavaScript.
- For INP: Profile real user interactions using the Long Animation Frames API or web-vitals.js. Identify which interactions are slow and why—usually it’s main thread contention from third-party scripts or heavy JavaScript execution.
- For CLS: Audit all elements that could cause layout shifts on load and during interaction. Define explicit dimensions for media, use font-display: optional or preload critical fonts, and hold space for any dynamically injected content.
- Apply the 80/20 Test
According to data from HTTP Archive, the most common causes of poor Core Web Vitals—slow LCP resources, render-blocking scripts, and undefined image dimensions—account for the majority of failures.
Fixing those three categories well will move the needle more than hunting edge cases.
What a CWV Audit Report Should Actually Include
- The Bare Minimum Is Not Enough
A screenshot of PageSpeed Insights is not an audit. A list of Lighthouse recommendations is not an audit.
A genuine Core Web Vitals audit report should give the agency enough information to make prioritised decisions and explain findings to clients credibly.
- What Belongs in the Report
- Field data by page template and device type—not just overall scores
- Lab data alongside field data, with an explanation of significant gaps
- The actual LCP element on each key page, identified on real devices, with its load path traced
- INP profiling results from real interactions, not just Lighthouse estimates
- CLS contributors identified and ranked by impact
- Prioritised fix recommendations linked to estimated field data impact, not just score improvement
- Third-party script inventory—these are frequently the primary cause of INP and CLS issues, and they’re often outside the agency’s direct control but still need surfacing
- A baseline and a measurement plan—so the fixes can be validated against real user data after deployment
The report should be actionable for a developer, understandable for a client, and honest about what the data does and doesn’t prove.
Conclusion: The Score Isn’t the Point
Core Web Vitals are a useful framework. They give performance work a shared vocabulary and a measurable target, which matters when you’re trying to make the case for technical investment.
But the metrics are proxies, not outcomes. A passing score is evidence that a page met a threshold on a particular device under particular conditions—nothing more.
The most valuable thing a CWV audit can do is close the gap between what the scores say and what users actually experience. That means taking field data seriously, being honest about the limits of lab testing, and resisting the temptation to optimise for the number rather than the person looking at the screen.
Agencies that understand this distinction do better performance work, and have better conversations with clients about what that work is actually worth.
Frequently Asked Questions
FAQs
Does a Good Core Web Vitals Score Guarantee Better SEO Rankings?
Not directly. Google has confirmed that Core Web Vitals are a ranking signal through its Page Experience update, but they operate as a tiebreaker rather than a primary factor.
Content relevance, authority, and structure matter far more for ranking. Passing CWV thresholds removes a potential ranking penalty but won’t rescue a page with weak content or poor backlink profiles.
How Often Should a Site’s Core Web Vitals Be Audited?
CrUX data rolls on a 28-day window, so scores can shift meaningfully after major deployments, third-party script changes, or seasonal traffic shifts.
A good practice is to monitor field data continuously using tools like Google Search Console or web-vitals.js, and schedule a full audit whenever scores drop materially or after significant site changes.
Why Do Core Web Vitals Scores Differ Between Google Search Console and PageSpeed Insights?
Search Console reports field data (real user experiences from CrUX), while PageSpeed Insights reports both field data and lab data from Lighthouse.
The lab score can differ significantly from the field score depending on your real user base’s devices and network conditions. Always anchor decisions to the field data, not the lab score.
Can Third-Party Scripts Fail a Site on Core Web Vitals Even If the Code Is Clean?
Yes—and this is one of the most frustrating realities of CWV work. Analytics platforms, chat widgets, ad networks, and tag manager payloads can introduce main thread blocking that tanks INP, inject content that causes CLS, and delay LCP by competing for bandwidth.
Audits should always include a third-party script inventory and assess their contribution to failures before recommending fixes to first-party code.
Is It Worth White-Labelling Core Web Vitals Audits for Agency Clients?
Absolutely. Performance audits are high-value deliverables that many agencies lack the in-house expertise to produce credibly.
Partnering with a specialist team allows agencies to offer robust CWV reporting under their own brand—without building the tooling or hiring the expertise themselves.
The key is ensuring the audit goes beyond Lighthouse screenshots and includes the field data analysis and prioritised recommendations that clients can actually act on.
