Core Web Vitals Explained: LCP, INP and CLS in Plain English

Core Web Vitals are the specific, measurable metrics Google uses to judge whether a webpage actually feels fast and stable to a real visitor — not a vague notion of "performance," but three precise numbers with defined thresholds. They matter for SEO because Google has explicitly folded them into page experience signals, but they matter even more directly for conversion and retention, since a slow or janky page loses visitors regardless of how it ranks.

Why Google cares about this at all

Google's stated goal with Core Web Vitals is aligning its ranking signals with what actually makes a page good to use, rather than purely content-and-links-based signals that say nothing about the visitor's actual experience once they land. A page that's technically well-optimised for keywords but takes eight seconds to become interactive, or that visibly jumps around as it loads, is a worse experience regardless of how relevant its content is — and Google's own research has consistently shown that visitors are measurably more likely to abandon slow or unstable pages before they even see the content.

LCP — Largest Contentful Paint

LCP measures how long it takes for the largest visible content element (usually a hero image, a large heading, or a prominent block of text) to render on screen — it's meant to approximate when the page's main content has actually become visible to the visitor, as opposed to a blank screen or a spinner. Google's threshold for "good" is 2.5 seconds or less; 2.5 to 4 seconds is "needs improvement"; above 4 seconds is "poor." Common causes of poor LCP include an unoptimised, oversized hero image, slow server response time, render-blocking CSS or JavaScript delaying when that main content can even start rendering, and web fonts that block text from displaying until they finish loading.

INP — Interaction to Next Paint (the metric that replaced FID)

INP measures the responsiveness of a page throughout its entire lifespan, not just its first interaction — specifically, the time between a user's interaction (a click, tap, or key press) and the next moment the browser visually updates in response. This replaced the older First Input Delay (FID) metric specifically because FID only measured the very first interaction, missing responsiveness problems that show up later in a session — a page that responds quickly to your first click but then becomes sluggish after a few interactions would have scored well on FID while genuinely frustrating real users, which INP is designed to catch. Google's threshold for "good" INP is 200 milliseconds or less; 200-500ms is "needs improvement"; above 500ms is "poor."

CLS — Cumulative Layout Shift

CLS measures visual stability — specifically, how much visible content unexpectedly shifts position while a page is loading or being used, which is the frustrating experience of trying to tap a button just as an ad or image loads above it and shifts everything down. It's scored as a unitless number based on how much of the viewport shifted and how far; Google's threshold for "good" is 0.1 or less; 0.1 to 0.25 is "needs improvement"; above 0.25 is "poor." The most common causes are images or ads without a reserved, explicit size (so the browser doesn't know how much space to leave before the content loads), web fonts that render differently than a fallback font and reflow the page, and content dynamically injected above existing content without reserving space in advance.

How to actually measure your own Core Web Vitals

• Google PageSpeed Insights — gives both lab data (a simulated test run) and, where enough real-world traffic exists, field data from the Chrome User Experience Report (CrUX) reflecting actual visitors' experiences.
• Google Search Console's Core Web Vitals report — shows field data aggregated across your entire site, grouped by how similar pages perform, which is the most useful view for prioritising fixes across many pages at once rather than one URL at a time.
• Chrome DevTools' Lighthouse panel — useful for local, in-progress testing while actively working on a fix, giving immediate lab-data feedback without waiting for real traffic to accumulate.

Practical fixes, mapped to each metric

• For LCP — compress and properly size images (see our Image Compressor), use a CDN, defer non-critical CSS/JS, and consider preloading the specific hero image or font that renders your largest element.
• For INP — break up long-running JavaScript tasks so the main thread stays free to respond to interactions, defer non-essential third-party scripts, and avoid excessive DOM complexity that slows down every re-render.
• For CLS — always specify explicit width/height (or aspect-ratio) on images and embeds, reserve space for ads and dynamically injected content in advance, and use font-display strategies that minimise the visual jump between a fallback font and the final web font.

Field data vs lab data — why your numbers might disagree

Lab data (from PageSpeed Insights' simulated run or Lighthouse) tests a single, controlled scenario — a specific device profile and network throttling setting — while field data (from Search Console or CrUX) reflects real visitors on their actual, hugely varied devices and connections. It's normal, and not a contradiction, for a page to score well in a lab test but show worse field data, since real-world visitors on older phones or slower mobile connections experience the page very differently than a controlled lab test does — field data is ultimately what Google's ranking systems weigh, making it the more important number to track over time even though lab data is more convenient for quick, repeatable testing during development.

How this actually ties into SEO ranking

Core Web Vitals are one signal among many in Google's ranking systems, generally understood to matter most as a tiebreaker between pages that are otherwise similarly relevant to a search query — exceptional Core Web Vitals scores won't rescue thin or irrelevant content, and conversely, reasonably good (not necessarily perfect) scores are unlikely to meaningfully hold back genuinely strong, relevant content. The more consistently significant impact tends to come through user behaviour signals — lower bounce rates and better engagement on faster, more stable pages — which correlate with, but are somewhat distinct from, the direct ranking weight of the Vitals themselves.

A simple checklist to start with

1. Run your key pages through PageSpeed Insights and note which of the three metrics is actually failing — fixing the right problem matters more than generic "speed" optimisation.
2. For LCP failures, start with your largest image or hero element — compression and proper sizing usually gives the biggest single improvement.
3. For CLS failures, audit every image, embed and ad slot for a missing explicit size.
4. For INP failures, look for large third-party scripts (chat widgets, analytics, ad scripts) that block the main thread, since these are frequently the biggest, easiest-to-defer culprit.
5. Recheck Search Console's field data periodically rather than relying solely on a one-time lab test, since field data takes time to accumulate and reflect a fix.

How field data is actually collected — the 28-day rolling window

Field data in Search Console and CrUX isn't updated instantly after you deploy a fix — it's based on a rolling 28-day window of real visitor data, meaning a change you deploy today typically won't be fully reflected in your reported scores for several weeks, as older data points gradually roll out of the window and get replaced by post-fix visits. This is a common source of confusion for anyone expecting an immediate before/after comparison — the correct expectation is that a genuine improvement shows up gradually over the following month, not instantly on the next page reload of the report.

Mobile vs desktop — why your scores can differ sharply

Google evaluates and reports Core Web Vitals separately for mobile and desktop, and it's common (especially for image- or script-heavy pages) for mobile scores to be noticeably worse, since mobile devices generally have less processing power and are more likely to be on slower, less reliable network connections than desktop visitors. Because Google's indexing and ranking are mobile-first, the mobile scores are generally the more consequential ones to prioritise fixing if your two sets of numbers diverge significantly, even if your own personal testing happens to be on a fast desktop machine that shows no problem at all.

Third-party scripts — often the biggest, least obvious culprit

A page's own code is frequently not the main source of poor INP or LCP — third-party scripts (chat widgets, ad networks, analytics tags, social media embeds, A/B testing tools) loaded from external domains routinely account for a disproportionate share of both blocking JavaScript execution time and delayed rendering, precisely because they're outside your direct control and often loaded without much scrutiny of their actual performance cost. Auditing exactly which third-party scripts are running (Chrome DevTools' Performance panel and Lighthouse both break this down explicitly) and removing or deferring ones that aren't earning their cost is frequently the single highest-leverage fix available, and one that's easy to overlook when attention focuses only on your own application code.

A realistic before/after scenario

Consider a blog page with a 3MB uncompressed hero image, four separate ad-network scripts loaded synchronously, and no explicit dimensions on any embedded content — a fairly typical, unremarkable setup for an ad-supported content site. Compressing the hero image to a properly sized, modern format, deferring the ad scripts to load after the main content renders, and adding explicit width/height to every image and embed commonly moves LCP from the "poor" range down into "good," and largely eliminates CLS entirely — none of which requires a framework migration or infrastructure change, just careful, deliberate attention to the handful of elements each metric is actually measuring.

Core Web Vitals as part of a broader page experience signal

Core Web Vitals sit alongside other page-experience factors Google has historically weighed — mobile-friendliness, the absence of intrusive interstitials, and safe-browsing status among them — as part of a broader assessment of whether a page is genuinely pleasant to use, not just technically fast. Treating Core Web Vitals as an isolated technical checklist to satisfy, disconnected from the rest of a page's actual usability, misses the underlying point: these three metrics are useful precisely because they're reasonable proxies for a real visitor's actual moment-to-moment experience, and improving them alongside genuinely useful, well-organised content tends to compound rather than substitute for each other.

Setting realistic expectations for improvement timelines

Meaningful Core Web Vitals improvements rarely come from a single change — they're usually the cumulative result of several smaller fixes (image optimisation, script deferral, explicit sizing) applied consistently across a site's templates rather than one page at a time. Prioritising your highest-traffic page templates first (a shared blog post layout, a shared product page template) means a single fix benefits every page using that template at once, which is a considerably more efficient use of effort than fixing one URL, then another, individually.

Framework and platform-specific considerations

Modern frontend frameworks (Next.js, Nuxt and others) increasingly bake in Core Web Vitals best practices by default — automatic image optimisation, built-in font-loading strategies, and route-level code splitting that limits how much JavaScript any single page needs to load — which is part of why migrating from an older, unoptimised setup to a modern framework often produces a meaningful Vitals improvement somewhat incidentally, as a side effect of the platform's own defaults rather than a dedicated performance project. That said, defaults alone don't guarantee good scores — a framework's image component still needs to be actually used correctly (real dimensions, appropriate formats), and a fast underlying platform can still be undermined by exactly the same heavy third-party scripts and unsized embeds that cause problems anywhere else.

Why perfect scores aren't the actual goal

Chasing a perfect 100 on every lab-data test is generally not a productive use of effort once you're solidly in the "good" threshold for all three metrics — the difference between a good score and a perfect one rarely translates into a noticeable ranking or user-experience difference, while the engineering effort to close that last gap often grows disproportionately. The more useful goal is consistently landing in "good" across your real-world field data for your important page templates, then redirecting further optimisation effort toward content quality and genuine usability improvements that matter more to an actual visitor than a marginally faster millisecond figure.