Core Web Vitals explained simply (no jargon)
Core Web Vitals are three metrics Google uses to measure real user experience: LCP (how long the main content takes to load), INP (how responsive the page feels when clicked or tapped), and CLS (how much the layout shifts unexpectedly). They're not the only ranking factor, but they're a genuine, checkable proxy for whether your site feels fast and stable to a real visitor.
Core Web Vitals sound like something only a developer should care about, but each of the three metrics measures something you've personally felt as a visitor: waiting for a page to finish loading, tapping a button that doesn't respond right away, or trying to click something just as the page shifts and you hit the wrong thing instead. They're an attempt to turn those felt experiences into numbers a site owner can actually check and improve.
There are three of them: LCP, INP, and CLS. Here's what each one measures, in plain English, and what typically causes a bad score.
LCP: how long the main content takes to appear
LCP stands for Largest Contentful Paint. It measures how long it takes for the largest visible element — usually a hero image, a big headline, or a banner — to finish rendering after someone lands on the page. It's meant to approximate the moment a visitor feels like the page has actually loaded, rather than the technical moment the page finishes loading in the background.
Google's published threshold considers an LCP of 2.5 seconds or less as good, with anything over 4 seconds considered poor. The most common causes of a slow LCP on a small business site are an oversized, uncompressed hero image, a slow hosting server responding to the initial request, or render-blocking scripts and stylesheets that delay the browser from painting anything.
INP: how responsive the page feels
INP stands for Interaction to Next Paint. It measures the delay between a visitor doing something — clicking a button, tapping a menu, typing into a field — and the page visibly responding. INP replaced an older metric called First Input Delay in 2024, because FID only measured the first interaction on a page, while INP measures responsiveness across every interaction during the visit, which is a more honest picture of whether a page feels sluggish throughout, not just at the start.
Google considers 200 milliseconds or less good for INP, with anything over 500 milliseconds poor. Bad INP is almost always caused by heavy JavaScript — the browser's main thread is busy running scripts (analytics tags, chat widgets, animation libraries, ad code) when the visitor interacts, so the response gets queued behind whatever the page is already doing.
CLS: how much the layout jumps around
CLS stands for Cumulative Layout Shift. It measures unexpected movement of visible elements while the page is loading or being used — the classic frustrating moment where you go to tap something and an ad or image loads in above it, shoving your target down just as you tap, so you hit the wrong thing entirely.
A CLS score of 0.1 or less is considered good, above 0.25 is poor. The usual culprits are images or ads without a reserved width and height, web fonts that load late and reflow text, or content injected dynamically above existing content without space held for it in advance.
| Metric | Measures | Good | Poor | Common cause |
|---|---|---|---|---|
| LCP | Loading speed of main content | ≤ 2.5s | > 4s | Oversized images, slow server response |
| INP | Responsiveness to interaction | ≤ 200ms | > 500ms | Heavy JavaScript blocking the main thread |
| CLS | Visual stability | ≤ 0.1 | > 0.25 | Images/ads without reserved space, late-loading fonts |
Why these particular three metrics
Google frames Core Web Vitals as page experience signals, and has said they're one of many ranking factors, not the dominant one — strong content that answers the query well will generally still outrank thin content on a technically faster page. What Core Web Vitals appear to influence more directly is user behavior on the page itself: a slow, jumpy, unresponsive page loses visitors before they ever get to your content, regardless of ranking. That's the more immediate, easier-to-verify reason to care about them.
Where to check your own scores
- •Google Search Console's Core Web Vitals report — shows real field data grouped by URL, based on actual visitors over the past 28 days
- •PageSpeed Insights — shows both field data (if enough traffic exists) and a lab test you can run on demand for any URL
- •Chrome DevTools' Lighthouse panel — a lab test you can run locally while making changes, useful during development
Why templates matter here
A lean, well-built HTML/CSS template starts you with a structural advantage on all three metrics: no bloated page-builder framework loading in the background, no unnecessary JavaScript for effects nobody asked for, and images with dimensions already specified so the browser can reserve their space before they load. It doesn't guarantee good scores — a huge uncompressed hero image or a poorly configured third-party widget can undo the advantage — but it removes a lot of the structural weight that heavier platforms carry by default.
- ✓LCP measures how long the main content takes to load; keep it under 2.5 seconds by compressing your largest image and using fast hosting.
- ✓INP measures how responsive the page feels to clicks and taps; keep it under 200ms by trimming unnecessary JavaScript.
- ✓CLS measures unexpected layout movement; keep it under 0.1 by always specifying image dimensions and avoiding late-injected content.
- ✓Core Web Vitals are one ranking signal among many, but a stronger, more direct influence on whether visitors stay once they land.
- ✓Check real scores in Search Console (field data) rather than relying only on a single lab test.