Core Web Vitals Explained
Understand Google's Core Web Vitals: Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift. Learn what they measure and how to pass.
Core Web Vitals are Google's standardised metrics for measuring real-world user experience on web pages. They evaluate three critical aspects: loading speed (LCP), interactivity (INP), and visual stability (CLS). Since 2021, they are part of Google's ranking algorithm — pages that pass Core Web Vitals have a ranking advantage.
- Core Web Vitals are three metrics that measure loading, interactivity, and visual stability.
- LCP (Largest Contentful Paint) — how quickly the main content loads. Target: under 2.5 seconds.
- INP (Interaction to Next Paint) — how quickly the page responds to user actions. Target: under 200 milliseconds.
- CLS (Cumulative Layout Shift) — how much the page layout moves during loading. Target: under 0.1.
- They are a confirmed ranking signal — pages that pass all three have a competitive advantage.
- Measured with real-world user data (field data), not just lab simulations.
If you want the full breakdown, continue below.
What Are Core Web Vitals?
Core Web Vitals are part of Google's broader "page experience" ranking signals. They were introduced in 2020, became a ranking factor in June 2021, and have been refined since — most notably when INP replaced FID in March 2024.
The three metrics address the most common user experience complaints:
- "The page is too slow" → LCP
- "The page does not respond when I tap/click" → INP
- "The content jumped around while loading" → CLS
LCP — Largest Contentful Paint
What It Measures
LCP measures when the largest content element in the viewport finishes loading. This is usually:
- A hero image
- A large text block (H1 heading)
- A video poster image
- A background image
LCP represents the point at which the user perceives the page as "loaded" — the main content is visible.
Thresholds
| Score | Rating |
|---|---|
| ≤ 2.5 seconds | Good ✅ |
| 2.5–4.0 seconds | Needs Improvement ⚠️ |
| > 4.0 seconds | Poor ❌ |
Common LCP Problems
Slow server response. The server takes too long to deliver the initial HTML. Fix: better hosting, CDN, server-side caching.
Render-blocking resources. CSS and JavaScript in the <head> prevent the page from rendering. Fix: defer non-critical resources, inline critical CSS.
Slow LCP resource loading. The hero image or main visual element takes too long to download. Fix: compress images, use WebP/AVIF, preload the LCP resource.
Client-side rendering. Pages that rely entirely on JavaScript to render content have delayed LCP because the browser must download, parse, and execute JS before showing content. Fix: use server-side rendering (SSR) or static generation (SSG).
LCP Optimisation Checklist
- Preload the LCP element:
<link rel="preload" as="image" href="hero.webp"> - Compress and resize the LCP image
- Do not lazy-load the LCP image
- Reduce server response time (TTFB under 200ms)
- Eliminate render-blocking CSS and JavaScript
- Use server-side rendering for content-heavy pages
INP — Interaction to Next Paint
What It Measures
INP measures the responsiveness of a page to user interactions — clicks, taps, and keyboard inputs. It captures the delay between when the user interacts and when the browser paints the visual update.
INP replaced FID (First Input Delay) in March 2024. While FID only measured the first interaction, INP measures all interactions throughout the page lifecycle and reports the worst-case scenario (with some outlier filtering).
Thresholds
| Score | Rating |
|---|---|
| ≤ 200 milliseconds | Good ✅ |
| 200–500 milliseconds | Needs Improvement ⚠️ |
| > 500 milliseconds | Poor ❌ |
Common INP Problems
Heavy JavaScript execution. Long-running scripts block the main thread, preventing the browser from responding to user input. Fix: break up long tasks, use web workers, defer non-critical JS.
Third-party scripts. Analytics, chat widgets, and ad networks often run expensive JavaScript that blocks interactivity. Fix: audit and remove non-essential scripts, load them asynchronously.
Complex DOM. Very large DOM trees (thousands of nodes) slow down rendering after user interactions. Fix: simplify page structure, use virtualisation for long lists.
Synchronous layout/style recalculations. JavaScript that reads layout properties (like offsetHeight) after making style changes forces the browser to recalculate layout synchronously. Fix: batch DOM reads and writes separately.
INP Optimisation Checklist
- Identify and break up long JavaScript tasks (over 50ms)
- Defer non-critical third-party scripts
- Use
requestIdleCallbackfor non-urgent work - Reduce DOM size (under 1,500 nodes ideally)
- Avoid forced synchronous layouts
- Use CSS for animations instead of JavaScript where possible
CLS — Cumulative Layout Shift
What It Measures
CLS measures the visual stability of a page — how much visible content moves during loading and interaction. Every time a visible element shifts position unexpectedly, it contributes to the CLS score.
Common causes of layout shift:
- Images loading without specified dimensions (content pushes down when the image appears)
- Ads or embeds injecting content that displaces existing elements
- Web fonts loading and changing text size/spacing
- Dynamic content inserted above existing content
Thresholds
| Score | Rating |
|---|---|
| ≤ 0.1 | Good ✅ |
| 0.1–0.25 | Needs Improvement ⚠️ |
| > 0.25 | Poor ❌ |
Common CLS Problems
Images without dimensions. When width and height are not specified, the browser does not know how much space to reserve. Fix: always set width and height on images and videos.
Dynamic content injection. Banner ads, cookie notices, or promotional bars that push content down. Fix: reserve space for dynamic content, or overlay it rather than displacing existing content.
Web font loading. When a web font loads and replaces the fallback font, text can resize and shift. Fix: use font-display: swap and size-adjust to match fallback dimensions.
Late-loading CSS. CSS that loads after the initial render can cause large layout changes. Fix: inline critical CSS, load non-critical CSS with lower priority.
CLS Optimisation Checklist
- Set explicit width and height on all images and videos
- Reserve space for ads and dynamic content with CSS
- Use
font-display: swapand optimise font loading - Inline critical CSS to prevent flash of unstyled content
- Never insert content above existing content after page load
- Test with Chrome DevTools Performance panel to identify shift sources
Lab Data vs Field Data
Lab Data (Simulated)
- Generated by tools like Lighthouse, PageSpeed Insights (lab section)
- Simulates a specific device and network condition
- Useful for debugging — consistent and reproducible
- Does not reflect real user experience
Field Data (Real Users)
- Collected from real users via the Chrome User Experience Report (CrUX)
- Reflects actual conditions: varied devices, networks, and locations
- Used by Google for ranking decisions
- Takes 28 days to accumulate sufficient data
- Shown in PageSpeed Insights (field section) and Search Console
Google uses field data for ranking. Lab data is useful for debugging, but your CrUX scores are what matter for SEO.
Key Takeaways
- Core Web Vitals measure loading (LCP), interactivity (INP), and visual stability (CLS).
- All three must pass their thresholds for the best ranking signal: LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1.
- Image optimisation and render-blocking elimination fix most LCP issues.
- JavaScript management fixes most INP issues.
- Specifying image dimensions and reserving space for dynamic content fixes most CLS issues.
- Google uses real-world field data for ranking — not lab simulations.
Tools & Resources (Coming Soon)
- Page Speed Checker (Coming soon)
- Core Web Vitals Monitor (Coming soon)
- Performance Audit Tool (Coming soon)
Related SEO Documentation
Was this helpful?