Core Web Vitals in 2026: what LCP, INP, and CLS actually measure
TL;DR: The three current Core Web Vitals are Largest Contentful Paint (LCP, measuring how quickly the largest visible content element renders), Interaction to Next Paint (INP, measuring how responsive the page is to user interaction throughout the entire visit, not just once), and Cumulative Layout Shift (CLS, measuring how much visible content unexpectedly shifts position during loading). INP officially replaced First Input Delay (FID) as the responsiveness metric in March 2024, which means content still referencing FID as a current Core Web Vital is outdated, worth being aware of since a fair amount of older guidance on this topic has not been updated to reflect the change.
Why these three specific metrics
Core Web Vitals represent Google's attempt to quantify genuine user-experienced page quality using metrics that correlate with what a real visitor actually perceives and is affected by, loading speed, responsiveness, and visual stability, rather than more abstract or purely technical performance measures that do not always translate to a visitor's actual felt experience. Each of the three current metrics addresses a genuinely distinct dimension of that experience, and a page can perform well on one while performing poorly on another, which is why all three are tracked and reported separately rather than being collapsed into one combined score.
LCP: Largest Contentful Paint
LCP measures the time from when a page begins loading to when the largest visible content element within the viewport, typically a hero image, a large block of text, or a prominent video thumbnail, finishes rendering. This is meant to approximate when a visitor perceives the page's main content as having actually loaded and become usable, a more meaningful proxy for perceived load speed than earlier metrics that measured technical loading milestones not necessarily aligned with what a visitor actually experiences as "the page is ready."
The current threshold for a "good" LCP score is 2.5 seconds or less. Common causes of poor LCP: a large, unoptimized hero image (covered in our WebP vs JPG vs PNG guide), slow server response time (covered in our full slow WordPress diagnostic guide), and render-blocking resources delaying when the browser can begin painting the largest content element at all.
INP: Interaction to Next Paint
INP measures the responsiveness of a page across the entirety of a visitor's interaction with it, capturing the latency between a user's interaction (a click, a tap, a key press) and the next visual update the browser paints in response, and specifically reporting a value representative of the worst (or a high-percentile) interaction observed during the full visit, rather than measuring only the very first interaction as its predecessor metric did.
This distinction matters genuinely: a page might respond quickly to the first click but become sluggish later in the visit, after more JavaScript has loaded and executed, or under some accumulated state that degrades performance over time, a pattern the older, first-interaction-only metric could not capture but INP specifically is designed to reflect. The current threshold for a "good" INP score is 200 milliseconds or less. Common causes of poor INP: heavy, unoptimized JavaScript execution (particularly from many plugins or a resource-intensive page builder each adding their own scripts), long-running tasks blocking the browser's main thread and delaying its ability to respond to new interactions, and excessive DOM complexity making each interaction's required processing more expensive.
CLS: Cumulative Layout Shift
CLS measures the total, cumulative amount of unexpected visual movement content undergoes during the page's loading lifecycle, the frustrating experience of a page's layout shifting after you have already started reading or, worse, right as you are about to tap a button, causing an accidental click on something else entirely because content moved at the last moment. This is calculated as a score based on how much of the viewport shifted and how far, aggregated across every unexpected shift during the page's load.
The current threshold for a "good" CLS score is 0.1 or lower. Common causes of poor CLS: images or embedded content (ads, iframes) loaded without explicit width and height dimensions specified in advance, causing the browser to reserve no space for them until they actually load and then abruptly shift surrounding content to accommodate them; web fonts loading and swapping in after an initial fallback font has already rendered and been read, shifting text as the final font's different sizing takes effect; and dynamically injected content (a cookie consent banner, a promotional popup) appearing above existing content and pushing it down unexpectedly after the visitor has already begun engaging with the page.
The FID-to-INP transition, and why it matters
First Input Delay (FID), the metric INP replaced, specifically measured only the delay before the browser could begin processing a visitor's very first interaction with the page, a narrower, less complete picture of overall responsiveness than INP's full-visit measurement provides. Google officially made INP the third Core Web Vital, replacing FID, in March 2024, meaning any content, tool, or guidance still referencing FID as a current, official Core Web Vital is working from outdated information, worth being specifically aware of since search results and older articles on this topic have not uniformly been updated to reflect this change, and conflating the two metrics or their thresholds leads to genuinely incorrect optimization priorities.
Practically, this transition means a site that scored well on the old FID metric is not automatically guaranteed to score well on INP, since INP's full-visit measurement can surface responsiveness problems (like the "slow to respond after JavaScript has loaded more content" pattern described above) that FID's first-interaction-only scope would never have detected at all.
A thresholds table
| Metric | Good | Needs Improvement | Poor |
|---|---|---|---|
| LCP | ≤ 2.5s | 2.5s – 4.0s | > 4.0s |
| INP | ≤ 200ms | 200ms – 500ms | > 500ms |
| CLS | ≤ 0.1 | 0.1 – 0.25 | > 0.25 |
How these tie back to actual ranking impact
Core Web Vitals are one confirmed input among Google's broader page experience ranking signals, meaningful but generally considered a smaller factor relative to content relevance and quality, which remains the dominant driver of ranking outcomes overall. This means Core Web Vitals optimization is worth genuine attention, particularly since poor scores can also directly affect visitor experience, engagement, and conversion independent of any ranking effect, but it should not be pursued at the expense of content quality under the mistaken assumption that a perfect Core Web Vitals score alone can compensate for weaker underlying content; the two work together rather than substituting for one another.
FAQs
Where do I check my site's actual Core Web Vitals scores?
Google Search Console's Core Web Vitals report shows real-world field data (from actual Chrome users, via CrUX) aggregated across your site over a rolling period, generally the most representative source; PageSpeed Insights shows both lab and field data for individual URLs, covered in more depth in our dedicated comparison.
Can a page have a good LCP but a poor INP, or do they usually move together?
Yes, they can and often do diverge, since they measure genuinely different things; a page with a fast-loading, well-optimized hero image (good LCP) can still have heavy, poorly optimized JavaScript causing sluggish interaction responsiveness later in the visit (poor INP), which is exactly why all three metrics need to be checked and addressed somewhat independently rather than assuming a good score on one implies good scores across all three.
Is CLS usually caused by images, or can other things cause it too?
Images without reserved dimensions are a very common cause, but web font loading behavior, dynamically injected content (ads, banners, consent notices), and any content that renders in a placeholder-less way before its final size is known can all contribute to CLS, meaning a full audit needs to check beyond just image dimensions alone.
Does mobile performance matter more than desktop for Core Web Vitals?
Google's Core Web Vitals assessment and the underlying field data are generally evaluated separately for mobile and desktop, and given that mobile devices and connections are typically more constrained, mobile scores often need more deliberate optimization attention, particularly if a meaningful share of your traffic is mobile.
How quickly do Core Web Vitals improvements show up in Search Console's report?
Since the report is based on rolling real-world field data (typically aggregated over the trailing 28 days), improvements take some time to be reflected as new, better-performing visits accumulate and gradually outweigh the older data in the rolling window, meaning results are not instantaneous even after a genuine, effective fix is deployed.
Is there a single overall Core Web Vitals score, or are the three metrics always reported separately?
They are fundamentally three separate metrics, each with its own threshold and assessment, though Search Console's report does present an overall pass/fail-style URL grouping based on whether all three metrics meet the "good" threshold together, giving a combined view without literally collapsing the three distinct measurements into one number.
Does fixing Core Web Vitals require a developer, or can I improve them myself?
Many common fixes (image optimization, enabling caching, covered in our full slow WordPress diagnostic guide) are achievable through plugin configuration without deep development skills; more involved JavaScript optimization for INP specifically sometimes benefits from developer involvement, particularly on sites with heavy custom functionality or many interacting plugins.
Conclusion
The three current Core Web Vitals, LCP, INP, and CLS, each measure a genuinely distinct dimension of real user experience: loading speed, ongoing interaction responsiveness, and visual stability, respectively. INP's replacement of FID in March 2024 is a meaningful update worth knowing, since it changed both which metric is officially tracked and what aspect of responsiveness is actually being measured, from a narrow first-interaction snapshot to a fuller picture across the entire visit.
Check your actual field data in Search Console rather than relying only on a single lab test, and address each metric's specific, distinct causes rather than assuming a fix for one automatically resolves the others, since they frequently diverge independently on real sites.
HostCloud's hosting includes server-level caching and optimization tuned specifically to improve LCP and INP, addressing the server-response and script-execution factors that most directly affect these metrics. Plans start at ₹99 a month at https://hostcloud.in.