Core Web Vitals are a set of three metrics that measure specific, real aspects of how a page feels to use — not a single abstract "performance score." Each one isolates a different kind of user-perceptible problem, which is also what makes them useful diagnostically: a poor score on one specific metric points toward a specific category of fix, rather than a vague instruction to "make the site faster."
What Core Web Vitals actually measure
The three current metrics are Largest Contentful Paint (loading speed, from the visitor's perspective), Interaction to Next Paint (responsiveness to input), and Cumulative Layout Shift (visual stability while the page loads). All three are measured based on real user experience patterns rather than purely synthetic lab conditions, which is why the same page can score differently depending on the devices and network conditions of the people actually visiting it.
A concrete example: before and after
A typical business homepage before a Core Web Vitals pass: a 4MB uncompressed hero photo sits at the top of the page with no explicit width or height set, three separate third-party scripts (analytics, a chat widget, a social embed) load synchronously in the page head before any content renders, and a promotional banner injects itself above the main heading a second after the rest of the page has already loaded. The result is a slow first paint (the browser can't start rendering until the render-blocking scripts finish), a further delay before the hero image itself appears, and a visible jump as the late-loading banner pushes the heading down — a poor LCP and a poor CLS from two unrelated causes on the same page.
After a pass addressing each cause directly: the hero image is compressed and served in a modern format with explicit dimensions set, so the browser reserves its space immediately; the third-party scripts are deferred so they load after the main content rather than blocking it; and the promotional banner's space is reserved in the layout from the start, so it fills into an already-allocated slot instead of pushing content when it arrives. None of these changes touch the actual page design — the fixes are about *how* the same content loads, not what the page contains.
LCP: Largest Contentful Paint
LCP measures how long it takes for the largest visible content element — usually a hero image, a large block of text, or a background image — to fully render within the viewport. It's meant to approximate "when does this page feel loaded" from a visitor's point of view, rather than measuring an arbitrary technical milestone that doesn't correspond to anything the visitor actually perceives. A good LCP is under 2.5 seconds; anything past 4 seconds is considered poor. In practice, a slow LCP almost always traces back to one of three causes: a slow server response time before the browser receives any content at all (time to first byte); render-blocking CSS or JavaScript in the page head that delays the browser from starting to paint anything, even content that's otherwise ready; or the LCP element itself — typically an image — being too large, uncompressed, or loaded after other lower-priority resources instead of being prioritized.
INP: Interaction to Next Paint
INP measures the latency between a visitor interacting with the page — a click, a tap, a key press — and the browser visually responding to that interaction. It replaced an earlier metric called First Input Delay specifically because it captures responsiveness across the entire page lifetime, not just the very first interaction. A good INP is under 200 milliseconds. Poor INP has a narrower set of causes than LCP: long-running JavaScript tasks blocking the browser's main thread are responsible for nearly all of it — a heavy script executing when a button is clicked, an inefficient event handler doing more work than necessary, or a large amount of synchronous processing (re-rendering a big component, running a complex calculation) happening directly in response to a single interaction instead of being broken into smaller chunks or deferred.
CLS: Cumulative Layout Shift
CLS measures unexpected visual movement of page content while it loads — the frustrating experience of a page shifting under a visitor's cursor right as they're about to click something. The practical causes are consistent across most sites: images or video embeds with no width/height (or CSS aspect-ratio) reserved, so the browser doesn't know how much space to leave until the file itself finishes loading; ads or third-party embeds that inject content into the page after the surrounding layout has already rendered; web fonts that swap in and change text size or line length after an initial fallback font has already been displayed; and content — banners, cookie notices, promotional bars — inserted above existing content rather than into a pre-reserved slot. A good CLS score is under 0.1, and the fix for essentially all of these causes is the same category of change: reserve the space before the content arrives, rather than resizing the layout once it does.
Why this affects more than just search ranking
Core Web Vitals are a confirmed component of search ranking, which is the reason they get discussed primarily as an SEO topic — but treating them purely as a ranking checkbox undersells what they actually measure. All three metrics track something a real visitor directly experiences: how long they wait, how responsive the page feels when they interact with it, and whether the page behaves predictably while it loads. Poor scores correlate with higher bounce rates and lower conversion independent of any search-ranking effect, because a slow, jumpy, unresponsive page is a worse experience regardless of how a visitor arrived at it.
A simple diagnostic workflow
Rather than guessing which of the three metrics is the problem, a short diagnostic pass identifies it directly: run the page through a Core Web Vitals measurement tool and note which of the three scores is poor — they're independent, so it's common for a site to fail one while passing the other two. If LCP is the issue, check time to first byte first (a slow server response delays everything downstream regardless of what else is optimized), then check whether the LCP element is render-blocked or unoptimized. If INP is the issue, look for the heaviest third-party or first-party script running on interaction, since that's the dominant cause in most real cases. If CLS is the issue, look specifically for images without reserved dimensions and any content that loads in above existing page content, since those two patterns account for most real-world CLS problems. Fixing metrics in isolation, based on which one is actually failing, is more efficient than applying every possible optimization to a page that only has one specific problem.
Fixing the most common causes
A practical, high-leverage starting list, roughly in order of typical impact for a standard business site: compress and correctly size images, and serve them in a modern format; eliminate render-blocking resources where possible, or defer non-critical CSS and JavaScript; set explicit dimensions on images and embedded content to prevent layout shift; audit third-party scripts (analytics, chat widgets, ad tags) for how much they contribute to both load time and main-thread blocking, since third-party code is a disproportionately common cause of both slow LCP and poor INP; and confirm the hosting environment itself has adequate CPU and fast storage — a slow time-to-first-byte at the server level puts every other optimization at a disadvantage before the page even starts rendering. NVMe storage specifically helps with the server-response-time component of LCP; see What Is NVMe Hosting for more on that piece. A secure, HTTPS connection is also a prerequisite for several modern performance features; see SSL Certificates Explained. For a site with a geographically spread-out audience, a CDN can also reduce the network-latency portion of LCP specifically — see What Is a CDN and When Does Your Website Need One?
