TL;DR
Core Web Vitals are Google’s performance metrics that directly influence search rankings. The three metrics are LCP (Largest Contentful Paint — how fast the main content loads), CLS (Cumulative Layout Shift — visual stability), and INP (Interaction to Next Paint — responsiveness). Most sites fail on LCP. The fixes are: optimise images, reduce server response time, eliminate render-blocking resources, and use a CDN. Target: LCP under 2.5s, CLS under 0.1, INP under 200ms.
What Are Core Web Vitals?
Core Web Vitals are three user-experience metrics that Google has integrated into its ranking algorithm:
| Metric | Measures | Good | Needs Improvement | Poor |
|---|---|---|---|---|
| LCP | Loading speed | < 2.5s | 2.5–4s | > 4s |
| CLS | Visual stability | < 0.1 | 0.1–0.25 | > 0.25 |
| INP | Interactivity | < 200ms | 200–500ms | > 500ms |
Sites that pass all three thresholds get a signal boost in Google search. Sites that fail lose ground to competitors who pass.
LCP: Largest Contentful Paint
LCP measures how long it takes for the largest visible element (usually a hero image or heading) to render.
Why sites fail LCP
- Large unoptimised images (the most common cause)
- Slow server response times (TTFB)
- Render-blocking JavaScript and CSS
- No CDN (serving from a single origin server)
How to fix LCP
1. Optimise your hero image
The hero image is almost always the LCP element. Fix:
- Convert to WebP or AVIF format (30–50% smaller than JPEG at same quality)
- Set
loading="eager"andfetchpriority="high"on the LCP image - Add
widthandheightattributes to prevent layout shift - Preload the image:
<link rel="preload" as="image" href="/hero.webp">
2. Reduce server response time (TTFB)
Target: under 800ms. Fix:
- Use a CDN (Vercel, Cloudflare, Fastly)
- Enable server-side caching
- Optimise database queries on dynamic pages
- Use static generation (Next.js SSG) where possible
3. Eliminate render-blocking resources
Audit with Chrome DevTools → Performance tab. Any <link rel="stylesheet"> or <script> in <head> without async or defer blocks rendering.
Fix:
- Load non-critical CSS asynchronously
- Defer non-critical JavaScript
- Inline critical CSS in
<head>
CLS: Cumulative Layout Shift
CLS measures unexpected movement of page elements as the page loads — the jarring experience of text jumping when an image loads above it.
Why sites fail CLS
- Images without explicit
widthandheightattributes - Ads or embeds that inject themselves into the layout
- Web fonts causing FOUT (Flash of Unstyled Text)
- Dynamically injected content above existing content
How to fix CLS
1. Always specify image dimensions
<img src="hero.webp" width="1200" height="630" alt="..." />
This lets the browser reserve the correct space before the image loads.
2. Reserve space for embeds
Give iframes and embed containers a fixed aspect ratio with CSS:
.video-wrapper {
aspect-ratio: 16 / 9;
width: 100%;
}
3. Preload fonts
<link rel="preload" href="/fonts/geist.woff2" as="font" type="font/woff2" crossorigin>
And use font-display: optional for fonts that aren’t critical to initial render.
INP: Interaction to Next Paint
INP replaced FID in 2024. It measures the delay between any user interaction (click, tap, keystroke) and the next visual response.
Why sites fail INP
- Long JavaScript tasks blocking the main thread
- Heavy third-party scripts (chat widgets, analytics, ad scripts)
- Unoptimised event handlers
- Large React re-renders
How to fix INP
1. Break up long tasks
Use setTimeout or scheduler.yield() to break JS work into smaller chunks under 50ms.
2. Audit third-party scripts
Every third-party script (chat widget, A/B testing, marketing pixels) adds to INP. Audit with Chrome DevTools → Performance → Third-party usage. Remove or defer scripts you can’t justify.
3. Optimise React rendering
In React apps, use useMemo, useCallback, and React.memo to prevent unnecessary re-renders. Use startTransition for non-urgent state updates.
Tools for Measuring Core Web Vitals
- PageSpeed Insights — field data + lab data for any URL
- Chrome DevTools → Lighthouse — lab data locally
- Chrome DevTools → Performance — deep-dive profiling
- WebPageTest — waterfall analysis, filmstrip view
- Google Search Console → Core Web Vitals — real user data from your actual visitors (most important)
Always prioritise field data (real users) over lab data (simulated). A page can pass Lighthouse but fail with real users on slow connections.
Frequently Asked Questions
Do Core Web Vitals actually affect rankings?
Yes, but it’s a tiebreaker signal — not a dominant factor. Google has confirmed that content relevance comes first. But in competitive niches where multiple pages are equally relevant, CWV can make the difference.
My site passes Lighthouse but fails in Search Console. Why?
Lighthouse uses a simulated device and network. Search Console uses real user data from Chrome browsers on real connections. Real users have slower devices, slower connections, and more browser extensions running — all of which hurt scores.
How often should I check Core Web Vitals?
After any significant code change, after adding new third-party scripts, and at least quarterly as a routine health check.
What’s the fastest way to improve LCP?
Optimise your hero image. This single change improves LCP on the majority of sites that fail it. Convert to WebP, add fetchpriority="high", and preload it.
Final Thoughts
Core Web Vitals are fixable engineering problems, not mysteries. Start with LCP (image optimisation + CDN), then CLS (image dimensions + font preloading), then INP (third-party audit + JS task splitting).