Core Web Vitals are three measurements Google takes from real visitors. LCP (Largest Contentful Paint) is how long until the biggest visible thing on the page appears — good is under 2.5 seconds. INP (Interaction to Next Paint) is how fast the page reacts to a click or tap — good is under 200 milliseconds. CLS (Cumulative Layout Shift) is how much the page jumps while loading — good is under 0.1.
Most explanations of those three acronyms read like they were written for the engineers who invented the metrics rather than the person deciding what to fix. This is the plain version. We've already made the business case for page speed — slow sites lose customers and rank worse — so this piece is the practical follow-up: what breaks each metric, and which one deserves your attention first.
Why the three of them exist
Google uses all three as a ranking signal. They also happen to track closely with whether people stay or leave — which is no coincidence. A page that loads slowly, responds sluggishly, and shifts under your thumb feels broken to a visitor who has never heard the phrase "Core Web Vitals" and never will.
What is LCP (Largest Contentful Paint)?
LCP clocks the time from the page starting to load until its largest visible element — usually a hero image, a big headline, a banner — finishes rendering.
Note what it isn't: it isn't "when is the page done." It's "when does the thing that dominates the screen actually exist," which turns out to be a decent proxy for whether a page feels loaded.
Google's thresholds: good is under 2.5 seconds, over 4 seconds is poor, and the range between is "needs improvement."
What breaks it
In practice, one of four things, and usually the first:
- 1.The LCP element is a huge, unoptimized image. A 3MB hero photo drags the score down every single time. Compress it, serve WebP or AVIF, and size it to the display dimensions rather than the 6000px original your camera produced (your camera is very proud of those pixels; the browser is not).
- 2.Slow server response. If the server takes 800ms to start sending anything, every downstream step inherits that delay. Cheap shared hosting is the usual suspect (you get what you pay $3.99 a month for).
- 3.Render-blocking CSS or JavaScript. When the browser must download and parse a pile of scripts before painting, your hero waits in line behind code that may not even run yet.
- 4.The LCP image discovered late. A hero buried in a CSS background rule, rather than sitting in an `
` tag, is invisible to the browser's early fetching — so it starts downloading later than it should.
The fix, ordered by yield
Preload the hero with ``. Serve modern formats at the right size. Get onto hosting that answers in under 200ms. Defer JavaScript that doesn't need to block rendering. In most audits we run, fixing the image alone covers 60–70% of the distance to a good score.
What is INP (Interaction to Next Paint)?
INP replaced FID (First Input Delay) as an official vital in March 2024, and the replacement was a real upgrade in honesty: FID graded only the first interaction, while INP grades responsiveness across the whole visit — every tap, every dropdown, every keystroke.
It measures the gap between a user interaction and the browser visually responding. Tap "Add to Cart" and watch nothing happen for a second? That's bad INP, even if the backend registered the click instantly. The user can't see your backend.
Thresholds: under 200 milliseconds is good, over 500 is poor.
What breaks it
JavaScript, nearly always.
Long tasks hogging the main thread are the classic case: if a heavy script is mid-execution when someone taps, the browser can't respond until it finishes. Third-party scripts — chat widgets, analytics, ad tags, embedded players — are habitual offenders here. (The live-chat widget nobody has staffed since 2024 is still charging you in milliseconds.) Beyond that: interactions doing too much work (big DOM re-renders, heavyweight handlers), and simply too many third-party scripts competing for one thread. A page carrying six marketing pixels and three chat tools is fighting itself.
The fix
Audit third-party scripts ruthlessly — everything that applies to page speed generally applies double here, because these scripts hijack the main thread at the worst moments. Break long tasks up so the browser can breathe between them (developers call this yielding to the main thread). Load non-essential scripts after the page is interactive. On a modern framework, check you're not re-rendering large component trees for every small interaction.
One observation from our own work: INP is the vital businesses are least prepared for, because it produces no obvious symptom. A site can load fast and look great, then feel like wading through syrup the moment someone starts clicking. Nobody notices until they measure.
What is CLS (Cumulative Layout Shift)?
CLS measures visual stability — how much content moves around during load. You know this one by feel: you go to tap a link, an ad loads above it in the final split second, everything lurches down, and you tap the wrong thing (usually the ad, which one suspects is not always an accident).
Thresholds: under 0.1 is good, over 0.25 is poor. The score is a computed function of how much of the viewport moved and how far — your tooling reports it; you never calculate it by hand.
What breaks it
Images and videos without declared dimensions, first and foremost. If the browser doesn't know how tall an image will be, it reserves no space, then shoves everything down when the image arrives. Ads and embeds injected without a reserved container do the same thing on a delay. Web fonts that swap in with noticeably different letter widths reflow whole paragraphs. And banners — cookie notices, promo bars — that push the page down after someone has already started reading.
The fix
Explicit width and height on every image and video (or CSS aspect-ratio). Fixed-size containers reserved for ads and embeds before they load. `font-display: optional` or preloaded key fonts to tame the swap. Dynamic banners either get their space reserved up front or overlay the content instead of shoving it.
Of the three vitals, CLS is usually cheapest to repair — it's rarely an architecture problem, more often a handful of missing dimension attributes someone can fix in an afternoon.
Do you actually need to care?
Depends what the site does for you.
Running paid traffic, or leaning on organic search? Core Web Vitals feed both your ad quality scores and your rankings — fix promptly. Running e-commerce or lead-gen forms? INP deserves particular attention, because a checkout button that feels dead costs sales directly, with or without Google watching. Running a low-traffic brochure site with no funnel riding on it? A "needs improvement" score is not an emergency. Put it on the list, not at the top.
Checking your numbers
Google gives the tools away:
- PageSpeed Insights (pagespeed.web.dev) — lab data for any URL, plus real-user field data when traffic is sufficient
- Search Console's Core Web Vitals report — real visitor data across the whole site, grouped by URL pattern
- Chrome DevTools' Performance panel — for the developer tracing exactly which script or image is responsible
Our free web analysis tools will also give you a quick read before you commit developer hours to chasing a score.
Keeping them straight
LCP: how fast the page appears. INP: whether it responds once someone uses it. CLS: whether it holds still while they do.
None of the three demands a rebuild. Nearly every fix is surgical — compress an image, defer a script, declare a dimension. The genuinely hard part is knowing which vital is hurting you and which specific resource is the cause, and that's what the measurement tools are for.
Not sure which Core Web Vital is dragging your site down? Our performance audits isolate the exact cause — the specific script, image, or layout issue costing you the score, not a page of generic advice. Check out our SEO services or get in touch and we'll look at your numbers.