Core Web Vitals are a subset of three metrics, within a broader group of page experience signals, that Google considers decisive enough for real user experience to turn into an explicit ranking factor. The three measure different aspects of the same question: does the page respond at the speed and with the stability a user expects, without them having to think about it? Understanding exactly what each one measures in technical detail is the only way to fix the actual cause instead of applying generic optimizations that don't target your site's specific problem.
LCP (Largest Contentful Paint): which element gets measured and why
LCP measures how long it takes to render, within the visible viewport, the largest content element of the initial load: usually a hero image, a background video, or a large text block if there are no images above it. The "good" threshold is 2.5 seconds or less; between 2.5 and 4 seconds is "needs improvement"; above 4 seconds is "poor." An important technical nuance: LCP doesn't measure when the page starts loading content, but when it finishes loading specifically the largest element, so optimizing small elements that aren't the LCP candidate doesn't move the metric at all.
The most frequent technical causes of a high LCP are, in order of impact: a slow server response to the initial request (high Time to First Byte, usually from an overloaded shared host or a missing server-side cache); render-blocking resources (large CSS or JavaScript loaded synchronously in the <head> before the browser can paint anything); and the LCP candidate image loaded without priority, a very common mistake when that image is defined in CSS as a background-image instead of as an <img> tag, because the browser discovers background-images much later in the load process than images declared in the HTML.
<!-- Helps the browser prioritize the LCP candidate image -->
<img src="hero.webp" fetchpriority="high" width="1200" height="600" alt="...">
<link rel="preload" as="image" href="hero.webp">INP (Interaction to Next Paint): the metric that replaced FID
INP measures a page's responsiveness to user interactions (clicks, taps, key presses) throughout the page's entire life, not just the first interaction. It replaced First Input Delay (FID) precisely because FID only measured the delay before the first interaction started being processed, completely ignoring how long that interaction took to complete visually, and also ignoring every other interaction that happens after the first one. The "good" threshold is 200 milliseconds or less.
The dominant technical cause of a high INP is main thread blocking: if JavaScript is running continuously (for example, a heavy analytics script, or a component recalculating state on every scroll), the browser can't process the user's next interaction until that JavaScript releases the thread. The technical fix isn't "reduce JavaScript" in the abstract, but splitting long tasks into smaller chunks that yield control back to the browser between them:
// Before: a long task that blocks the main thread
processThousandsOfItems(list);
// After: chunked, yields control between batches
function processInBatches(list, i = 0) {
const batch = list.slice(i, i + 50);
process(batch);
if (i + 50 < list.length) {
setTimeout(() => processInBatches(list, i + 50), 0);
}
}CLS (Cumulative Layout Shift): the shift you don't always consciously notice
CLS measures the sum of every unexpected shift of visible elements throughout the page's life, expressed as a unitless score (not seconds, not pixels) that combines how much content shifts and what fraction of the viewport it affects. The "good" threshold is 0.1 or less. The most common cause, and the easiest to fix, is images with no declared dimensions: if an <img> tag has no width and height (or its CSS equivalent, aspect-ratio), the browser can't reserve the space it will occupy before downloading it, so surrounding content "jumps" when the image finishes loading.
<!-- Bad: no dimensions, the browser doesn't reserve space -->
<img src="product.webp" alt="Nordic chair">
<!-- Good: reserves the exact space before the image loads -->
<img src="product.webp" width="400" height="400" alt="Nordic chair">Other frequent causes of high CLS: banners, cookie notices or chat widgets inserted dynamically above existing content without previously reserving their space; web fonts that replace a system font after loading (FOIT/FOUT), changing text size and shifting everything below it; and ads inserted into containers with no minimum height defined.
Why field data (CrUX) and lab data (Lighthouse) don't always match
Google uses two distinct data sources and it's common for them to show contradicting results without that meaning a measurement error. Lab data (Lighthouse, the "audit" part of PageSpeed Insights) runs a controlled simulation, a single time, under fixed network and hardware conditions. Field data (Chrome User Experience Report, CrUX) is the real aggregation of real Chrome users' visits, with all the variety of devices and network conditions that implies, over the last 28 days. For ranking, Google uses exclusively field data (CrUX); lab data is a prior diagnostic tool, not the source that determines the ranking factor.
How to prioritize what to fix first in a real diagnosis
The most efficient priority order isn't fixing the worst metric in the abstract, but fixing first the cause that affects the most pages across the site's templates: if LCP fails because the server is slow to respond, that problem affects every page equally and fixing it (server-side caching, better hosting) has immediate impact across the whole domain; if CLS only fails on pages with one specific chat widget, the fix is local to that component and doesn't require touching the rest of the site.
Frequently asked questions
Are Core Web Vitals the most important ranking factor?
No: Google describes them as one signal among many, weighted less than the content's relevance to the search. Their effect is more decisive as a tiebreaker between pages of similar relevance than as a lever capable of outweighing higher-quality content.
Can my Lighthouse score improve without the actual ranking improving?
Yes, it's a common case: Lighthouse measures under controlled lab conditions, while the ranking factor uses real field data (CrUX) from the last 28 days. A lab improvement takes time to show up in field data, and only does so if it translates into a real improvement for real users.
Can CLS be eliminated entirely?
In practice, yes, in the vast majority of cases: the cause is almost always identifiable (images with no dimensions, dynamically inserted content, web fonts) and fixable with the techniques described in this guide, without needing significant design trade-offs.
Is INP measured the same way on mobile and desktop?
It's measured with the same methodology, but Google's reference thresholds are mostly designed around the typical performance of mid-range mobile devices, which are far more CPU-constrained than a desktop computer; an acceptable INP on desktop may not be acceptable on mobile with the same code.
Is it worth optimizing Core Web Vitals if my site already looks fast at a glance?
Yes, because "looks fast" and "is fast according to the metrics" don't always match: a page can look visually loaded (visible content) while the main thread is still blocked and unresponsive to clicks (high INP), or while elements keep shifting below the initial scroll (high CLS from later interactions).