Core Web Vitals, explained without the jargon

"Core Web Vitals" gets thrown around like a compliance checkbox — something a developer ticks off and everyone else ignores. That's backwards. The three metrics behind the name aren't arbitrary; they're Google's attempt to measure something every visitor already feels: does this page show up fast, does it respond when I touch it, and does it stop jumping around while I'm trying to read it. You don't need to understand the measurement to understand the problem it's pointing at.

The three things it actually measures

Strip away the acronyms and each one maps to a real moment in a visitor's experience:

• Largest Contentful Paint (LCP) — how long until the main thing on the page (usually a hero image or headline) actually appears. Slow LCP feels like staring at a blank or half-loaded page.
• Interaction to Next Paint (INP) — how long the page takes to respond after someone taps a button or a menu. Bad INP feels like the site is ignoring you, even briefly.
• Cumulative Layout Shift (CLS) — how much content jumps around as the page finishes loading. Bad CLS is the reason you've tapped the wrong button because an ad or image loaded in late and pushed everything down.

Why this isn't just a Google trivia score

These metrics feed into Google's ranking signals, so yes, there's an SEO angle — but treating that as the whole story undersells it. A slow, jumpy site loses visitors regardless of where it ranks: people abandon slow pages before they ever see your offer, and a mistapped button from a layout shift is a lost enquiry, not a technicality. Good Core Web Vitals scores are a symptom of a well-built site, not the goal in themselves — chase the underlying build quality and the score follows.

What actually causes bad scores

In practice, it's almost always one of a short list of usual suspects:

• Unoptimised images — a photo straight off a phone or camera, served at full resolution to a phone-sized screen, is the single most common cause of slow LCP.
• Too many third-party scripts — analytics tags, chat widgets, ad pixels and tracking scripts each add their own load time and often block the page from responding, hurting INP.
• Web fonts and embeds loading late — text or images that reserve no space until they arrive cause the layout to jump, which is exactly what CLS penalises.
• Page builder and template bloat — visual builders often ship far more code than a given page needs, and that overhead adds up across every metric at once.
• No lazy loading strategy — pulling in everything below the fold immediately, instead of as the visitor scrolls to it, slows the initial load for content nobody's looking at yet.

How to actually check yours

You don't need to guess. Google's free PageSpeed Insights tool (search it, paste your URL) scores all three metrics for both mobile and desktop and points at specific causes on your page. If you've got Google Search Console set up, its Core Web Vitals report shows real visitor data over time rather than a single test — that's the more honest picture, since a single test can vary run to run depending on network conditions.

The fix isn't always what people assume

Compressing one hero image won't rescue a site built on a heavy template with a dozen tracking scripts bolted on — and conversely, ripping out every third-party tool isn't realistic if your business genuinely needs the analytics or chat widget. Treat it as an ongoing discipline rather than a one-off fix: check scores periodically, question every new script before it gets added, and when a rebuild is on the table, ask explicitly how page speed and layout stability are being handled — not just how the site looks in the mockups.