Core Web Vitals get explained badly more often than almost any other SEO topic, usually because whoever is explaining them wants to sound technical instead of wanting you to understand them. Here is the version I actually want clients to walk away with, using the ocean because I cannot help myself and because the analogies genuinely hold up.
LCP: how long until the wave actually arrives
Largest Contentful Paint measures the time until the biggest visible element on the screen — usually a hero image, a heading, or a big block of text — has fully rendered. It is not "page load time" in the old sense. It is: how long does a visitor stare at a blank or half-formed page before the thing they came for shows up.
Think of it as paddling out and waiting. A two-second wait for the set to arrive is fine, expected, no one leaves. A twelve-second wait and people paddle in. Google's threshold for "good" LCP is 2.5 seconds. The most common cause we find in audits, in order:
- An unoptimized hero image — full-resolution photography served at three or four times the pixels the screen actually needs, with no modern format (AVIF or WebP) and no responsive sizing.
- Render-blocking JavaScript and CSS — scripts in the
<head>that the browser must download and execute before it can paint anything below them. - Web fonts loading without a fallback strategy, which either blanks text until the font arrives or swaps it late enough to feel janky.
- Slow server response time (TTFB) — often the real culprit, and the one people investigate last because it feels like someone else's problem.
INP: how the board responds when you shift your weight
Interaction to Next Paint replaced First Input Delay in 2024 as the official responsiveness metric, and it is a better one because it measures the worst interaction across the entire visit, not just the first click. It is the gap between you doing something — tapping a menu, submitting a form, opening an accordion — and the page visibly responding.
This is the difference between a board that turns the instant you shift your weight and one with a half-second of mushy delay before it responds. You feel it immediately, even if you cannot name what is wrong. The usual causes:
- Heavy third-party scripts — chat widgets, ad tags, analytics suites, and marketing pixels that monopolize the main thread exactly when a user is trying to interact.
- Large JavaScript bundles that have to be parsed and executed before event handlers are even attached, common on page builders and heavily plugin-dependent CMS setups.
- Poorly optimized event handlers doing expensive work (large DOM updates, unthrottled scroll listeners) synchronously.
CLS: the deck that stays put underneath you
Cumulative Layout Shift measures how much visible content jumps around as the page loads. An ad slot pops in and shoves the paragraph you were reading down the screen. A web font swaps in at a different width and reflows three lines of text. You tap a button and an image loads above it a half-second later, so you tap the wrong thing instead.
It is standing on a board that stays exactly where you put your feet versus one that slides out from under you. The fixes are mechanical and almost always the same: reserve space for images and embeds with explicit width and height (or aspect-ratio), reserve space for ads and dynamic content instead of letting it push everything else down, and load fonts with font-display: optional or a closely matched fallback so text does not reflow when the real font arrives.
Where to actually look
Four tools cover nearly everything you need, and they answer different questions:
- Search Console's Core Web Vitals report shows real field data grouped by URL pattern, which is the closest thing to ground truth for how Google sees your rankings-relevant performance. Start here.
- PageSpeed Insights blends both — field data at the top if your site has enough CrUX traffic to qualify, lab data (a live Lighthouse run) below it. Useful for a quick gut check on any single URL.
- Lighthouse in Chrome DevTools is the debugging tool — it gives you a request waterfall, flags the specific element responsible for your LCP, and calls out the exact scripts blocking the main thread. This is where you actually diagnose the fix, not just the score.
- The Chrome UX Report public dataset(via BigQuery or the CrUX API) is worth pulling if you want to benchmark against a competitor's field data, which PageSpeed Insights also happens to expose for any public URL you plug in.
The workflow we actually run: Search Console tells us which templates are failing in the real world, Lighthouse tells us why, and PageSpeed Insights is the fastest way to confirm a fix worked before waiting a month for CrUX's rolling window to catch up and reflect it.
Field data versus lab data — and why they disagree
This trips up more people than the metrics themselves. Lighthouse (lab data) runs a single simulated page load on a fixed device and network profile in a controlled environment. It is great for debugging because it is reproducible and gives you a waterfall to stare at.
The Chrome User Experience Report, CrUX (field data), is what Google actually uses for ranking. It aggregates real anonymized visits from actual Chrome users on their actual devices and networks over a rolling 28-day window. A site can score perfectly in Lighthouse on a fast office connection and still fail CWV in the field because most of its real visitors are on mid-range Android phones on patchy cellular connections. If your Lighthouse score and your Search Console Core Web Vitals report disagree, believe the field data — it is describing your actual audience, not a lab conditions.
How much this actually affects rankings
Honestly: less than the amount of content written about it would suggest. Core Web Vitals are one signal among hundreds, and Google has been fairly consistent that they function more as a tiebreaker between pages that are otherwise similarly relevant than as a dominant ranking factor on their own. A page with mediocre CWV but genuinely better content will usually still outrank a faster page that answers the query worse.
Where Core Web Vitals matter enormously — arguably more than for rankings — is conversion. Every major study on this, including Google's own retail data, shows a fairly linear relationship between load time and bounce rate, and between layout stability and form completion rate. We treat CWV as a user-experience and revenue problem first, and an SEO benefit that comes along for the ride second. That framing tends to get budget approved faster too.
What fixing it actually involves
Most sites can get LCP and CLS into the good range with targeted work: compressing and correctly sizing images, deferring non-critical JavaScript, self-hosting and preloading key fonts, and auditing which third-party scripts are actually earning their keep. INP is usually the hardest of the three because it often means genuinely reducing JavaScript execution, not just deferring it — there is no lazy-loading trick for a bloated bundle that has to run eventually.
Sometimes the honest answer is that the platform itself is the problem. A site built on a page-builder plugin stack with a dozen third-party embeds is fighting its own foundation, and incremental fixes hit a ceiling fast. That is usually when we recommend a rebuild rather than another round of patches — every site we design goes out the door with green Core Web Vitals baked into the markup rather than bolted on after, which is the whole premise behind our web design and development work. If you are weighing a rebuild for this exact reason, it is worth reading how we approach it without losing the rankings you already have.