PERFORMANCE
Core Web Vitals: LCP, INP, and CLS — What They Are and How to Fix Each
A practical guide to Google's three Core Web Vitals: what Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift measure, why they're ranking signals, and how to diagnose and fix each.
Published July 12, 2026 · 9 min read
Core Web Vitals are three metrics Google uses as ranking signals. Unlike traditional SEO signals (backlinks, keyword density), they measure real user experience: how fast does the page load? How quickly does it respond to taps and clicks? Does the layout jump around while loading?
This guide covers what each metric actually measures, how to find your scores, and — most importantly — what to do when they're in the red.
What are Core Web Vitals?
Core Web Vitals are a subset of Google's Page Experience signals. As of 2024, there are three:
| Metric | What it measures | Good | Needs Improvement | Poor | |--------|-----------------|------|-------------------|------| | LCP | Load time of the largest visible element | <2.5s | 2.5–4.0s | >4.0s | | INP | Latency of the slowest interaction | <200ms | 200–500ms | >500ms | | CLS | Layout stability during load | <0.1 | 0.1–0.25 | >0.25 |
Critical point: Google uses field data, not lab scores. Field data comes from real Chrome users visiting your page, aggregated in the Chrome User Experience Report (CrUX). Lab scores from PageSpeed Insights (the Lighthouse tool) are useful for diagnosis but are not what Google's ranking systems use. A page can score 90 in Lighthouse lab conditions but have poor CrUX field data — and it's the CrUX data that influences ranking.
LCP — Largest Contentful Paint
What it measures
LCP is the time from when the browser starts loading a page to when the largest image or text block visible in the viewport is rendered. "Largest" is measured by rendered pixel area. Typically the LCP element is the hero image, the main article image, or the H1 if no image is present.
Why it matters
LCP correlates strongly with perceived load speed — it's the moment the page looks "done enough to read." A 2.5-second LCP feels fast; a 5-second LCP feels broken.
How to find your LCP element
In Chrome DevTools: open Performance tab → reload the page → find the "LCP" marker in the timeline. The LCP element is highlighted in the viewport overlay.
In PageSpeed Insights: the Diagnostics section shows the LCP element with a screenshot.
How to fix slow LCP
1. Preload the LCP image. If your LCP element is an image, add a <link rel="preload"> in the <head>:
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">
Do not use loading="lazy" on the LCP image — lazy loading defers the image, which directly increases LCP.
2. Use next-gen image formats. WebP is 25–35% smaller than JPEG at equivalent quality. AVIF is another 20–30% smaller than WebP. Both are supported by all modern browsers.
3. Remove render-blocking resources above the LCP image. Synchronous <script> tags in the <head> block the browser from rendering anything until the script executes. Move scripts to the bottom of <body> or add defer / async.
4. Use a CDN for image delivery. Images served from the same server as your HTML add a sequential request. A CDN co-located with users delivers images in parallel with the HTML parse.
5. Eliminate unnecessary redirect chains before the page. Each redirect adds a round-trip. A chain of http:// → https:// → www. → non-www. can add 300–600ms before the browser starts loading any resource.
INP — Interaction to Next Paint
INP replaced FID (First Input Delay) as a Core Web Vital in March 2024.
What it measures
INP measures the latency between a user interaction (click, tap, key press) and the next paint after that interaction — for the slowest interaction during the page visit. Unlike FID, which only measured the delay before the browser could start processing the event, INP measures the complete delay until the browser updates the visual display.
A page with INP of 200ms means the slowest interaction — across all clicks and taps during a typical session — took 200ms before the page visually updated.
Why it matters
Poor INP makes a page feel sluggish or broken. Tapping a button that takes 600ms to show any response creates the same "is this working?" anxiety as a slow-loading page. For e-commerce, search-heavy, and interactive UIs, INP is often the most impactful metric.
How to diagnose poor INP
INP is hard to reproduce in lab conditions because it depends on which interactions users make. The most reliable signal is CrUX field data. In Google Search Console → Core Web Vitals, check which pages have INP in "Needs Improvement" or "Poor".
For diagnosis, use Chrome DevTools Performance panel during representative user interactions. Look for long tasks (yellow bars) that overlap with your interaction handler.
How to fix poor INP
1. Yield to the main thread. Long-running JavaScript tasks (>50ms) block the browser from responding to interactions. Break them up with scheduler.yield() (or setTimeout(0) as a fallback):
for (const item of largeDataSet) {
processItem(item);
if (needsYield()) await scheduler.yield(); // yield between iterations
}
2. Defer non-critical JavaScript. Third-party scripts (analytics, chat widgets, A/B testing tools) often run on the main thread. Load them with defer or after the first user interaction.
3. Reduce DOM size. Browsers repaint more of the DOM when the DOM is large. Pages with 1,500+ DOM nodes are more likely to have high INP. Virtualise long lists (only render visible rows).
4. Avoid layout-triggering reads inside event handlers. Reading layout properties (offsetWidth, getBoundingClientRect()) inside a click handler forces a synchronous layout recalculation — the browser must recalculate the layout before returning the value. Batch reads before writes.
CLS — Cumulative Layout Shift
What it measures
CLS measures how much the page layout shifts unexpectedly during load. Each layout shift is scored by the fraction of the viewport that moved and how far it moved. CLS is the sum of all unexpected layout shift scores during the page's lifetime.
A CLS of 0.1 is essentially invisible. A CLS of 0.5 means the user experienced visible layout jumps — buttons jumping under their cursor, text jumping as an image loads above it.
Why it matters
Layout shifts cause misclicks — the "I was about to tap the back button and the page jumped and I tapped an ad" experience. They're also the most user-visible CWV failure: the classic banner ad or cookie notice that pushes content down is a textbook CLS failure.
How to find CLS issues
In Chrome DevTools: open Rendering panel (from the three-dot menu → More tools) → enable "Layout Shift Regions". Reload the page. Blue flashes show elements that shifted.
In PageSpeed Insights: the Diagnostics section lists "Avoid large layout shifts" with the specific elements causing shifts.
How to fix high CLS
1. Add width and height attributes to all <img> elements. Browsers calculate aspect ratio from these attributes and reserve space before the image loads:
<img src="hero.webp" width="1200" height="630" alt="...">
Without dimensions, the browser can't reserve space and the layout shifts when the image arrives.
2. Reserve space for dynamically inserted content. Ads, embeds, banners, and cookie notices that appear above content cause CLS. Use min-height on the container to reserve space before the content loads.
3. Avoid inserting content above existing content after load. Prepending a banner or notification above a paragraph that was already rendered forces everything below it to shift down.
4. Use CSS transform for animations. Animating top, left, margin, or padding causes layout recalculations and CLS. Animating transform (which runs on the compositor thread) doesn't.
5. Preload custom fonts. If a fallback font loads first and then a custom font replaces it, the layout shifts if the fonts have different metrics. Use font-display: optional to skip the swap if the custom font isn't available, or size-adjust in @font-face to make fallback metrics match.
How to check your Core Web Vitals
Google Search Console (most authoritative): Core Web Vitals report → shows CrUX field data per page group, 28-day window. Good for identifying which pages have problems.
PageSpeed Insights: enter a URL → shows both field data (CrUX, when available) and lab data (Lighthouse). Good for per-URL investigation.
DeepSEOAnalysis free audit: the full audit pulls CrUX field data for all crawled pages and surfaces which pages have "Needs Improvement" or "Poor" status per metric, with specific fixes per failing metric.
Chrome DevTools: Performance panel for local reproduction; Rendering panel for CLS debugging.
Core Web Vitals and ranking
Google confirmed that Core Web Vitals became a ranking signal in 2021. The signal operates at the page URL level (not just domain level) and uses a 28-day rolling window of CrUX data.
The ranking impact is real but often marginal compared to relevance — a page that exactly matches search intent will typically outrank a faster page that partially matches it. But between two pages with equal content quality, the better Core Web Vitals page has a measurable advantage.
The practical priority: fix CWV for pages that already rank in positions 5–20 on competitive queries. These pages are in range for ranking improvement and CWV is a legitimate differentiator at that level.
Frequently asked questions
What's the difference between Core Web Vitals field data and lab data?
Field data comes from real Chrome users visiting your site (collected via CrUX). Lab data comes from Lighthouse running a synthetic page load in a controlled environment. Google's ranking system uses field data. Lab data is useful for reproducing and diagnosing problems — it's consistent and controllable — but a good lab score doesn't guarantee good field data, and vice versa.
How long does it take for CWV improvements to affect ranking?
CrUX data updates on a 28-day rolling window. Once you deploy a fix, it takes up to 28 days for the full impact to show in field data. Google's ranking systems update periodically, so expect 4–8 weeks from deployment to seeing ranking effects from CWV improvements.
Which Core Web Vital is most important to fix first?
Fix whichever is in "Poor" status first, since "Poor" is the threshold below which Google's ranking signal is negative. Within "Poor" pages, LCP is usually the highest priority because it affects every page load. CLS is often the easiest to fix (adding width/height to images). INP requires the most diagnosis to address, since it depends on user interaction patterns.
Do Core Web Vitals affect all pages or just the homepage?
All pages — Core Web Vitals are measured per URL. Your homepage might be "Good" while key product or article pages are "Needs Improvement". Check Google Search Console's Core Web Vitals report for the full distribution across your site.
MORE FROM THE BLOG
Related articles
10 min read
On-Page SEO: The Complete Checklist for 2026
On-page SEO covers every element you control on the page itself — title tags, headings, content, internal links, structured data, and image optimisation. Here's the full checklist and what to prioritise.
Read →8 min read
Duplicate Content and SEO: What Causes It, What Harms Rankings, and How to Fix It
Duplicate content means the same text appears at multiple URLs — Google picks one version to index and ignores the rest. Here's what actually causes it, when it damages rankings, and the canonical tags and redirects that fix each case.
Read →8 min read
XML Sitemap: What It Is, How to Create One, and What to Check
What an XML sitemap does, what to include and exclude, how to submit it to Google, and how to check it for common errors — with examples for Next.js, WordPress, and static sites.
Read →Run DeepSEOAnalysis on your own site.
Free, no signup. Technical SEO, Core Web Vitals, structured data, and AI visibility in one report.
Run a free audit →