How We Run a Core Web Vitals Audit
From Lighthouse Scores to Real-User Data
Why Core Web Vitals audits often fail in practice
Many websites technically "pass" Core Web Vitals - yet still feel slow, unstable, or frustrating to use.
At the same time, other sites fail Lighthouse scores but perform well in real life.
The reason is simple:
Core Web Vitals are user experience signals, not synthetic test scores.
A meaningful audit cannot rely on a single tool or snapshot. It must combine lab data, real-user data, and architectural analysis.
What Core Web Vitals actually measure
Google's Core Web Vitals focus on three metrics:
- LCP (Largest Contentful Paint) - how fast the main content becomes visible.
- INP (Interaction to Next Paint) - how responsive the page is to user interactions.
- CLS (Cumulative Layout Shift) - how visually stable the layout is during loading.
These metrics do not measure "speed" in isolation - they measure perceived quality of experience.
Why Lighthouse alone is not enough
Lighthouse provides lab data:
- controlled environment,
- simulated device and network,
- single-page snapshots.
This is useful for debugging, but it does not represent:
- real devices,
- real networks,
- real user behavior,
- logged-in states,
- cookie and consent logic.
Relying on Lighthouse alone often leads to:
- optimizing the wrong things,
- chasing scores instead of impact,
- regressions in real usage.
Step 1: Understand the business context
Before looking at metrics, we clarify:
- Which pages are entry points?
- Which pages generate leads or revenue?
- Which audiences matter (mobile vs desktop, region, device)?
Core Web Vitals optimization without context leads to wasted effort.
Step 2: Analyze real-user data (RUM)
We prioritize field data, typically from:
- Google Search Console (CWV report),
- Chrome User Experience Report (CrUX),
- GA4 performance events (where available).
This tells us:
- which pages actually fail CWV,
- on which devices,
- for which users,
- and how consistently.
A page that fails CWV for 5% of users needs a different approach than one failing for 60%.
Step 3: Identify patterns, not isolated scores
Instead of fixing individual URLs, we look for patterns:
- layout-level issues,
- shared components,
- global scripts,
- design system constraints.
Core Web Vitals problems are rarely page-specific - they are architectural.
Step 4: Controlled lab testing
Only after understanding real-user behavior do we use:
- Lighthouse,
- WebPageTest,
- browser performance profiles.
Here we answer why a metric fails:
- What blocks LCP?
- What causes long tasks affecting INP?
- What triggers layout shifts?
Lab tools explain causes - not impact.
Step 5: Map issues to root causes
Typical root causes include:
- oversized JS bundles,
- late-loading fonts or images,
- heavy third-party scripts,
- hydration delays,
- unstable layout components,
- unscoped CSS.
Each issue is mapped to:
- affected pages,
- affected metrics,
- estimated business impact.
Step 6: Prioritize fixes realistically
Not all CWV issues deserve equal attention.
We prioritize based on:
- user impact,
- SEO importance of pages,
- effort vs gain,
- risk of regression.
The goal is meaningful improvement, not perfect scores.
Step 7: Validate with real users
After changes:
- we monitor CWV field data,
- check trends, not snapshots,
- confirm improvements persist across devices.
Core Web Vitals optimization is iterative, not one-off.
How this impacts SEO and conversion
Proper CWV improvements typically lead to:
- better mobile engagement,
- lower bounce rates,
- higher form completion,
- more stable rankings over time.
Google rewards consistency and quality - not temporary score spikes.
Key takeaway
A real Core Web Vitals audit:
- starts with users, not tools,
- combines field data and lab analysis,
- focuses on root causes,
- prioritizes business impact.
Optimizing for Lighthouse alone is easy.
Optimizing for users - and search engines - requires method.