Core Web Vitals Explained: LCP, INP & CLS

Two pages. Same topic. Similar backlinks. Nearly identical content quality. One ranks on page one — the other sits on page three. The difference is often invisible to the human eye but completely visible to Google: page experience.

Core Web Vitals are the specific user experience metrics Google uses to measure that experience. They are not a theory or a future signal — they have been confirmed Google ranking factors since 2021, and in 2026 they also influence which pages get cited in AI Overviews. Yet the majority of sites still fail at least one of the three metrics.

This guide cuts through the noise. You will learn exactly what LCP, INP, and CLS measure, why each one matters for your rankings, what causes poor scores, and the highest-impact fixes for each — without retreading the broader technical SEO foundations covered separately in the Technical SEO Guide 2025.

What are Core Web Vitals?

Core Web Vitals are three user-experience metrics defined by Google to measure the real-world performance of web pages: Largest Contentful Paint (LCP) for load speed, Interaction to Next Paint (INP) for responsiveness, and Cumulative Layout Shift (CLS) for visual stability. Since 2021, passing all three thresholds is a confirmed ranking signal within Google's Page Experience system.

They are measured using field data — real Chrome user sessions collected through the Chrome User Experience Report (CrUX) — not lab simulations. This distinction matters: a page can look fast in a local Lighthouse test and still fail in Google's actual field data.

One critical update to flag for 2026: INP replaced FID (First Input Delay) as the interactivity metric in March 2024. If your site's CWV strategy still references FID, it is operating on outdated information.

The complete thresholds at a glance

MetricWhat it measuresGoodNeeds improvementPoorLCPLargest visible element loaded< 2.5 s2.5 – 4.0 s> 4.0 sINPWorst interaction delay in session< 200 ms200 – 500 ms> 500 msCLSTotal unexpected layout shift< 0.10.1 – 0.25> 0.25TTFB*Server response time (related)< 800 ms800 ms – 1.8 s> 1.8 s * TTFB is not a Core Web Vital but is the most common root cause of poor LCP scores.

LCP — Largest Contentful Paint

LCP answers one question: when does the user see that the page is actually loading something useful? It measures the time from the first navigation request to when the largest visible content element — typically a hero image, a large heading, or a banner — is fully rendered in the viewport.

Good

< 2.5 s

Needs improvement

2.5 – 4.0 s

Poor

> 4.0 s

What causes poor LCP?

LCP is a chain reaction. If any link in the chain is slow, the whole metric fails. The four most common culprits are:

• Slow server response time (TTFB): if the server takes 2 seconds to respond, LCP cannot possibly score under 2.5 seconds — no amount of front-end optimisation can compensate for a slow server.
• Render-blocking resources: CSS and JavaScript files placed in the <head> that must fully download and parse before the browser can display anything. Every millisecond of blocking delay pushes LCP further out.
• Unoptimised LCP element: a hero image served as a 2MB PNG instead of a compressed WebP, or a font-rendered heading that waits for a font file to load before it appears.
• Client-side rendering: if your LCP element is injected by JavaScript, Googlebot must wait for the JS execution wave — which can add seconds to the perceived load time.

How to improve LCP — by impact order

• Add fetchpriority="high" to your LCP image: this single attribute tells the browser to fetch the LCP resource before anything else. It is the fastest LCP win available — a one-line HTML change.
• Preload the LCP resource: add <link rel="preload" as="image"> in the <head> for the LCP image so the browser discovers and begins fetching it immediately.
• Compress and convert images to WebP or AVIF: typically reduces image file size by 30–50% with no visible quality loss.
• Improve TTFB first: if your TTFB is above 800 ms, fix the server before touching anything else. Use a CDN, enable server-side caching, or upgrade hosting.
• Eliminate render-blocking scripts: defer all non-critical JavaScript with the defer attribute. Inline only the critical CSS needed for above-fold content.

Common mistake: Never lazy-load your LCP image. Adding loading="lazy" to the image that is your LCP element is one of the most damaging single-line errors in performance optimisation — it tells the browser to delay loading the exact element Google is measuring.

INP — Interaction to Next Paint

INP is the newest Core Web Vital and the one most sites are currently failing. It measures the delay between a user interacting with the page — clicking a button, tapping a link, pressing a key — and when the browser visually responds to that interaction.

The key difference from its predecessor FID: FID only measured the first interaction on a page. INP measures the worst interaction across the entire user session. A page that loads fast but freezes whenever a user clicks a filter or opens a menu will fail INP even if it passes LCP and CLS.

Good

< 200 ms

Needs improvement

200 – 500 ms

Poor

> 500 ms

What causes poor INP?

• Long JavaScript tasks on the main thread: any JS task over 50 ms blocks the browser from responding to user input. Modern JS-heavy frameworks (heavy React trees, large Vue components) are the most common INP offender.
• Third-party scripts: analytics platforms, chat widgets, A/B testing tools, and ad scripts frequently execute synchronously on the main thread, consuming the budget INP depends on.
• Heavy event handlers: click listeners that trigger expensive DOM updates, recalculations, or API calls without being debounced or throttled.
• Large DOM size: pages with 1,500+ DOM nodes take longer to process interactions because the browser must evaluate more elements on each update.

How to optimise INP — by impact order

• Break up long JavaScript tasks: any task over 50 ms should be split into smaller chunks using setTimeout(fn, 0) or the newer scheduler.yield() API to allow the browser to process interactions between tasks.
• Defer all non-critical third-party scripts: load analytics, chat, and social embeds after the page is fully interactive using a tag manager with async loading, or by adding them dynamically post-load.
• Audit your event handlers: remove expensive synchronous operations from click/touch listeners. If a handler must do heavy work, move the processing to a Web Worker off the main thread.
• Reduce DOM size: aim for under 1,500 total DOM nodes. Remove unused markup, virtualise long lists, and avoid deeply nested component trees.

Diagnostic tip: In Chrome DevTools, open the Performance panel and record a session where you trigger the sluggish interaction. Look for red-flagged long tasks in the main thread track. Click the task to see which script is responsible — this is almost always faster than guessing.

CLS — Cumulative Layout Shift

CLS is the most relatable Core Web Vital because every user has experienced it: you are about to tap a button and suddenly an ad loads above it — you tap the wrong element. Or you are mid-sentence in an article and the text jumps down as a banner appears.

CLS measures the total amount of unexpected visual shifting of page content during the page's lifespan. It is a unitless score calculated by multiplying the fraction of the viewport that shifted by the distance it moved. A CLS of 0.1 means roughly 10% of the viewport shifted by 10% of its height.

Good

< 0.1

Needs improvement

0.1 – 0.25

Poor

> 0.25

What causes poor CLS?

• Images without explicit dimensions: if an <img> tag has no width and height attributes, the browser does not reserve space before the image loads. When it arrives, the page reflows — everything below the image shifts down.
• Ads, embeds, and iframes with no reserved space: very common on publisher, news, and e-commerce sites. Ad slots that expand on load are among the worst CLS offenders.
• Dynamically injected content above existing content: cookie banners, pop-ups, notification bars, and chat widgets that appear above the fold after the page has loaded.
• Web font swapping: a heading renders in a fallback system font, then shifts when the branded font loads — FOUT (Flash of Unstyled Text) causes CLS even though it looks like a font issue.

How to fix CLS — by impact order

• Add explicit width and height to every image and video: this one fix resolves CLS for the majority of sites. It allows the browser to reserve the exact space before the resource loads.
• Reserve space for ads and embeds: set a min-height on ad containers, or use the CSS aspect-ratio property to hold dimensions before content loads.
• Use font-display: swap or font-display: optional in your @font-face declarations: swap allows text to appear immediately in a fallback font; optional tells the browser to use the fallback if the custom font is not already cached.
• Preload key fonts in the <head>: adding <link rel="preload" as="font"> for your primary fonts significantly narrows the window in which font swapping can cause layout shift.
• For CSS animations: only animate transform and opacity properties. Animating width, height, top, or left forces the browser to recalculate layout on every frame — causing CLS and harming INP simultaneously.

How to Measure Your Core Web Vitals Scores

The most important distinction in CWV measurement is lab data versus field data. Lab data is simulated — useful for debugging but not what Google uses for ranking. Field data comes from real Chrome users in the wild, collected via the Chrome User Experience Report (CrUX) — and that is what determines your actual ranking impact.

• Google Search Console (Core Web Vitals report): the most actionable tool for SEO — shows field data across URL groups, flags pages failing thresholds, and groups similar pages together. Check this first.
• PageSpeed Insights: shows both lab and field data for any URL. The filmstrip at the top shows exactly when your LCP element appears. The Opportunities section prioritises fixes by estimated impact.
• Chrome DevTools Performance panel: the best tool for diagnosing INP and LCP root causes. Record an interaction, identify long tasks, trace them to the responsible script.
• Web Vitals Chrome extension: displays LCP, INP, and CLS scores in real-time as you browse your own site — useful for spotting CLS events on specific pages or interactions.

Start With the Metric That Hurts Most

If you are prioritising fixes, follow this sequence: LCP first, CLS second, INP third. LCP improvements — particularly TTFB, image optimisation, and removing render-blocking resources — tend to have the broadest impact and the quickest implementation path. CLS is usually resolved with a handful of HTML attribute additions. INP is the hardest but the most differentiated opportunity, since most sites have not yet tackled it seriously.

In 2026, Core Web Vitals matter beyond traditional search. Google's AI Overviews and third-party AI search engines are increasingly using page experience signals as a quality proxy when selecting sources to cite. A page that loads fast, responds instantly, and never shifts unexpectedly is more likely to be trusted and cited — by both algorithms and real users.

Measure now

Open PageSpeed Insights, paste your homepage URL, and find your LCP element in the filmstrip — that is your starting point.

Get expert help

Book a free Core Web Vitals audit at harigopinath.com — find the top 3 fixes that will move your scores fastest.

Read next

Technical SEO Guide 2025 — the complete foundation that Core Web Vitals sits within, covering crawlability, indexation, and more.