Core Web Vitals directly impact your search rankings. Google confirmed in March 2024 that page experience signals remain a ranking factor for mobile and desktop results. Here's a practical, step-by-step method to audit them in under 10 minutes â no paid tools needed.
The Three Metrics That Matter
| Metric | Threshold (Good) | What It Measures |
|---|---|---|
| LCP (Largest Contentful Paint) | Under 2.5 seconds | Loading speed |
| INP (Interaction to Next Paint) | Under 200 milliseconds | Interactivity |
| CLS (Cumulative Layout Shift) | Under 0.10 | Visual stability |
Google replaced FID with INP in March 2024, so ignore any older guides still referencing FID.
Step 1: Run a Quick Lab Test (2 minutes)
Open Chrome DevTools (F12), navigate to the Lighthouse tab, and run a performance audit. Check the Core Web Vitals section in the report. Record your scores:
- LCP: Look for the green/red/blue bar in the audit
- INP: Available in Chrome 123+ Lighthouse reports
- CLS: Shown as a numeric score in the layout section
Lighthouse gives you lab data â useful for debugging, but it doesn't reflect real user conditions.
Step 2: Pull Real User Data (3 minutes)
Go to PageSpeed Insights (pagespeed.web.dev) and enter your URL. This pulls actual Chrome UX Report (CrUX) data from real users. Compare your lab scores with field data.
Key numbers to check:
- 75th percentile LCP â your slowest 25% of users experience worse than this
- INP at P75 â interactivity under real conditions
- CLS field data â whether real shifts exceed the 0.10 threshold
If lab and field data diverge significantly, your hosting infrastructure or network conditions are the bottleneck.
Step 3: Identify the Root Cause (3 minutes)
Back in DevTools, use the Performance tab to record a page load:
- Click Record, reload the page, stop recording
- Check the Network tab for resources over 100 KB â these are your LCP candidates
- Filter by Waterfall to spot render-blocking JavaScript files
- Look for Layout Shifts in the Experience section â these explain CLS issues
Common fixes based on what you find:
- LCP over 2.5s: Compress images (use WebP at quality 80), enable CDN caching, defer non-critical JS
-
INP over 200ms: Reduce event handler complexity, debounce scroll/input listeners, use
requestIdleCallback -
CLS over 0.10: Set explicit
widthandheighton images, reserve space for dynamic ads, usefont-display: swap
Step 4: Check Mobile Specifically (2 minutes)
Switch to mobile device simulation (Ctrl+Shift+M in DevTools). Run Lighthouse again with mobile throttling. Mobile scores often differ by 30-50% from desktop.
Pay attention to:
- Total blocking time over 200ms indicates heavy JS
- Main thread work should stay under 3 seconds
- Offscreen images â lazy-load anything below the fold
Quick Reference: What "Good" Looks Like
| Metric | Red Flag | Target | Excellent |
|---|---|---|---|
| LCP | > 4.0s | < 2.5s | < 1.2s |
| INP | > 500ms | < 200ms | < 50ms |
| CLS | > 0.25 | < 0.10 | < 0.01 |
The One Thing Most Developers Miss
The most common Core Web Vitals failure I see isn't technical â it's failing to monitor field data continuously. Set up a free monitoring schedule: run PageSpeed Insights weekly for your top 10 pages and track the P75 numbers in a spreadsheet. A single deployment can push INP from 120ms to 800ms if a third-party script is added without performance testing.
Audit weekly, fix within 48 hours of any regression, and your scores will stay green.
Top comments (0)