Reading a Core Web Vitals report without panicking

Google Search Console shows a Core Web Vitals report, half the rows are orange or red, and the recommended fixes read like they were written for someone who already understands the problem well enough not to need the report. This happens to nearly every client who has not had a developer looking at this specific data before. The good news: there are only three metrics that matter, they measure three genuinely different things, and each one has a short list of causes that account for most real-world problems.

LCP — Largest Contentful Paint

What it measures: how long until the biggest visible element on the screen — usually a hero image, a headline, or a banner — has actually rendered. This is the metric most people mean when they say a page "feels slow to load," because it is the moment the page looks finished, even if smaller things are still loading behind the scenes.

What usually causes it: an oversized hero image that was never compressed or resized for the display it is shown at, a web font blocking text from rendering until it downloads, or a slow server response before the browser can start building the page at all. In roughly that order of frequency.

The fix that accounts for most cases: compress and correctly size images (a 4000px-wide photo displayed at 800px wide is pure waste, every single load), and load the largest above-the-fold image with priority instead of letting it compete with everything else on the page.

INP — Interaction to Next Paint

What it measures: how long the page takes to visibly respond after someone clicks, taps or types. This replaced an older metric called First Input Delay, and it is stricter — it measures the worst interaction on the page, not just the first one, so a page that feels fine on first click but stutters on a later one now shows up correctly as a problem.

What usually causes it: too much JavaScript running on the main thread at once, often from third-party scripts — chat widgets, analytics tags, ad tech — that were added one at a time over the years and never audited together as a group.

The fix that accounts for most cases: audit every third-party script actually running on the page (most sites are surprised by how many there are), remove what is not earning its keep, and defer what is not needed immediately on load.

CLS — Cumulative Layout Shift

What it measures: how much visible content jumps around while the page is loading — the specific annoyance of trying to tap a button and having an ad or image load in above it a half-second earlier, shifting everything down.

What usually causes it: images and embeds (ads, videos, iframes) without a reserved width and height, so the browser does not know how much space to leave for them until they have already loaded and pushed everything else out of the way.

The fix that accounts for most cases: explicit width and height attributes on every image and embed, and reserved space for anything that loads asynchronously — a banner, a cookie notice, a webfont swap.

What "good" actually looks like

Google's current thresholds, measured at the 75th percentile of real visits: LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1. Note the 75th percentile part — a report showing "poor" means at least a quarter of real visits are worse than that, which is a meaningfully large problem, not an edge case to shrug off.

We measure this on real sites, not in a lab, because lab tools run on a fast machine with an empty cache — the exact opposite of a real visitor's actual phone on real mobile data. A page that looks perfect in a lab test and scores poorly in the field almost always has a real-world problem the lab never sees.

The order to fix things in

LCP first — it is usually the biggest score impact and the cheapest fix (image compression is often a single afternoon of work). INP second, since a third-party script audit takes longer and needs sign-off on what gets removed. CLS last, because once images have explicit dimensions, most sites see that number settle on its own without further work.