Core Web Vitals are Google's attempt to measure whether a page feels good to use. They're a real but modest ranking factor — you will not outrank a better page by being faster. What they genuinely do is stop you losing the visitors you already paid for. On a slow mobile site, a large share of people leave before they see anything at all, and no amount of SEO fixes that.
There are three metrics. Here's what each one means, what usually breaks it, and what we fix first.
LCP — Largest Contentful Paint
What it measures: how long until the biggest thing on screen appears. Usually your hero image or headline. It's a proxy for "when does this page look like it loaded".
Target: under 2.5 seconds. Over 4 seconds is a failure.
What usually breaks it
- An oversized hero image. Far and away the most common cause. Someone uploads a 4MB photo straight from a camera and the browser downloads all of it before painting.
- Slow hosting. Cheap shared hosting located on another continent from your customers. If your clients are in Dubai and your server is in Texas, every single request pays that round trip.
- Render-blocking resources. Stylesheets and fonts the browser must fetch before it can draw anything.
- Content injected by JavaScript. If the hero text only appears after a script runs, LCP waits for the script.
What to do
- Serve images as WebP or AVIF, sized to how they're actually displayed. A hero shown at 1200px wide does not need a 4000px file. This one change routinely halves LCP.
- Preload the hero image:
<link rel="preload" as="image" href="hero.webp"> - Never lazy-load the hero. Lazy-loading is for images below the fold; applying it to the LCP element makes the score worse.
- Put a CDN in front of the site so assets are served near the visitor.
- Self-host fonts, or at minimum
preconnectto the font host and usefont-display: swapso text shows immediately in a fallback. - Set explicit
widthandheighton images — helps here and is essential for CLS below.
INP — Interaction to Next Paint
What it measures: when someone taps or clicks, how long before the screen visibly responds. INP replaced the old First Input Delay metric, and it's stricter — it looks at interactions across the whole visit, not just the first one.
Target: under 200ms. Over 500ms is a failure.
What usually breaks it
- Too much JavaScript. The main thread is busy running scripts, so it can't respond to the tap.
- Third-party tags. Chat widgets, heat-mapping tools, ad pixels, review widgets, popup builders. Each one is someone else's code running on your page. We have seen sites with eleven of these, none of which anyone was using.
- Heavy work inside event handlers — filtering a large list, rebuilding a whole section of the DOM on every keystroke.
- Page builder bloat. Some WordPress builders ship several hundred kilobytes of JavaScript to render a page that is, functionally, text and a form.
What to do
- Audit third-party scripts and delete the ones nobody reads the output of. This is usually the biggest single win and costs nothing.
- Load what remains with
defer, or after user interaction rather than on page load. A chat widget that appears two seconds in is fine; one that blocks the first tap is not. - Debounce expensive handlers on search and filter inputs.
- Break long tasks up so the browser gets a chance to respond between chunks.
- Give instant visual feedback on click — a pressed state or spinner — so even slow work feels acknowledged.
CLS — Cumulative Layout Shift
What it measures: how much the page jumps around while loading. This is the metric behind the universal experience of going to tap a button and hitting an ad instead.
Target: under 0.1.
What usually breaks it
- Images without dimensions. The browser doesn't know how much room to leave, so everything below jumps when the image arrives.
- Web fonts swapping in at a different size to the fallback, reflowing every paragraph.
- Banners injected at the top after load — cookie notices, promo bars, announcement strips.
- Ads and embeds in containers with no reserved height.
What to do
- Put
widthandheighton every image and video, always. Modern CSS keeps them responsive while reserving the right space. - Reserve height for any embed, ad slot or dynamically inserted banner.
- Match your fallback font's metrics to the web font, or use
size-adjust, so the swap doesn't reflow text. - Overlay cookie and promo banners rather than pushing content down.
How to measure it honestly
There's a distinction that trips up most people: lab data versus field data.
Lighthouse in Chrome DevTools gives you lab data — a simulated load on your machine, on your connection. Useful for debugging, but it is not what Google ranks on.
Google uses field data: real Chrome users on real devices and real networks, aggregated over 28 days. You'll find it in Google Search Console under the Core Web Vitals report, and in PageSpeed Insights at the top of the page. A green Lighthouse score with a failing field report means your visitors are on slower phones and worse connections than you are — which, for most SME audiences, they are.
Test on a mid-range Android phone on mobile data, not on your laptop on office wifi. That's the device your customer is holding.
Two more things worth knowing. Field data updates on a rolling 28-day window, so a fix you shipped today won't fully show up for a month — don't panic and undo it in week two. And scores are reported per URL group, so a fast homepage can sit alongside a failing set of product pages.
The realistic priority order
- Compress and resize images. Cheapest fix, biggest LCP gain, nearly every site needs it.
- Delete unused third-party scripts. Free, immediate INP improvement.
- Add width and height to every image. An afternoon of work, usually fixes CLS outright.
- Move hosting closer to your customers, or add a CDN. Real cost, real result.
- Reduce JavaScript. Most effort, and on a page-builder site it often means rebuilding — worth it when the site is a real revenue channel.
Most small business sites can pass all three metrics with the first three items on that list. If you're being sold an expensive "performance optimisation" package before anyone has looked at your image sizes, ask why.
Want to know where your site stands?
We'll run the real field data on your pages and send you a plain-English list of what's slowing them down and what it would take to fix.
Get a free speed check ↗