We touched on Core Web Vitals briefly in our mobile-first design guide, but they come up in every SEO report we run and deserve a proper explanation on their own. They're the three metrics Google uses to measure how a page actually feels to use — not how it looks in a screenshot, but how it behaves for a real visitor on a real connection.
Largest Contentful Paint (LCP) — how fast the main content appears
LCP measures the time until the biggest visible element on the page — usually a hero image, a heading, or a large block of text — has fully rendered. Google's thresholds:
- Good: under 2.5 seconds
- Needs improvement: 2.5–4 seconds
- Poor: over 4 seconds
The most common cause of a poor LCP on small business sites is a large, unoptimised hero image — often a beautiful photo that was never compressed, saved in the wrong format, or loaded before anything else on the page has a chance to render.
A real example from this site: our own homepage hero doesn't use a photo at all — it's a lightweight animated SVG sketch. That wasn't a stylistic accident. A hero photo (and the preload hint that usually goes with it) is one of the most common LCP killers on small business homepages, so we deliberately removed it rather than fighting to make a heavy image load fast. Sometimes the best fix for LCP isn't optimising the large element — it's not needing one.
Practical fixes:
- Compress and serve images in WebP, sized to the actual display dimensions — not the original camera resolution
- Avoid loading web fonts in a way that blocks text from appearing (`font-display: swap` helps)
- Don't hide the hero content behind JavaScript that has to run before anything appears
- If you must use a large hero image, preload it — but only if nothing else on the page matters more
Cumulative Layout Shift (CLS) — whether the page jumps around while loading
CLS measures unexpected movement of visible elements as a page loads. You'll have felt this yourself: you go to tap a button, and in the split second before your finger lands, an ad or image loads above it and the whole page shifts — so you tap the wrong thing.
- Good: under 0.1
- Needs improvement: 0.1–0.25
- Poor: over 0.25
The usual causes:
- Images or embeds (like a Google Maps widget) with no `width` and `height` set, so the browser doesn't reserve space for them before they load
- Web fonts that load in and suddenly change the size or spacing of existing text
- Content — banners, cookie notices, "sign up" prompts — injected above existing content after the page has already rendered
Fixes are mostly about reserving space in advance: always set explicit dimensions on images and embeds, and choose font-loading strategies that don't cause a visible reflow.
Interaction to Next Paint (INP) — how quickly the page responds to input
INP measures the delay between a visitor tapping, clicking, or typing, and the page visibly responding. It replaced an older, narrower metric (First Input Delay) because it captures responsiveness across the whole time on the page, not just the very first interaction.
- Good: under 200 milliseconds
- Needs improvement: 200–500 milliseconds
- Poor: over 500 milliseconds
Poor INP is almost always caused by too much JavaScript running on the main thread at once — heavy scripts, large animation libraries, or third-party embeds (chat widgets, tracking pixels, video players) all competing for the browser's attention at the exact moment a visitor tries to interact.
This is one of the reasons we default to plain CSS animation over JavaScript animation libraries wherever possible: CSS animations run off the main thread, so they don't compete with a visitor's tap or scroll for the browser's attention.
Why these three, and not something simpler like "page load time"
A single load-time number hides where things actually go wrong. A page can finish loading in a fast overall time yet still feel terrible to use, if the content that matters loads late (poor LCP), the layout keeps shifting (poor CLS), or every tap has a lag (poor INP). Measuring all three separately is what makes it possible to diagnose which part of the experience needs fixing, rather than guessing.
What this means for your site
Core Web Vitals are field metrics — Google increasingly weighs real visitor experience data over lab test scores, which means a site can test well in a tool but still perform poorly for actual visitors on real phones and real mobile signal. This is exactly the gap our free SEO report is built to catch: it checks your Core Web Vitals alongside the rest of your technical SEO, so a slow-loading image or a layout-shifting embed doesn't sit undetected on your site for months.
If you want to see how your own site scores on all three, get your free report — or read how these scores feed into your overall website health score.