Why your site is slow — and the Core Web Vitals fixes that move rankings in 2026

If you've ever watched your own website load on a mid-range phone over patchy mobile data, you already know the feeling: the header appears, then nothing, then a flash of text, then an image shoves everything down just as you go to tap a button. That experience has a name now — or three names — and Google measures all of them. They're called Core Web Vitals, and they're a real, if modest, ranking signal.

The good news is that the fixes are rarely glamorous and almost never require a rebuild. Let's start with what's actually being measured.

The three metrics that matter

1. Largest Contentful Paint (LCP) — how fast the main content loads

LCP measures the moment the biggest visible element — usually a hero image, a headline, or a banner — finishes rendering. Google wants this under 2.5 seconds for 75% of your visits. When a page feels slow to "appear," LCP is almost always the culprit.

The usual offenders: an enormous unoptimised hero image, a slow server response, or a font that blocks text from showing. Fixing LCP is mostly about getting the most important thing on screen first and getting everything else out of its way.

2. Interaction to Next Paint (INP) — how responsive the page feels

INP replaced the old First Input Delay metric in 2024, and it's stricter. It measures the lag between a user action — a tap, a click, a keypress — and the screen visibly responding. The target is under 200 milliseconds. When a menu takes half a second to open or a button feels "mushy," that's poor INP, and it's usually caused by heavy JavaScript hogging the main thread.

3. Cumulative Layout Shift (CLS) — how stable the page is

CLS quantifies that maddening jump where content moves after it's already on screen — an image loading without reserved space, an ad slot expanding, a web font swapping in at a different size. Google wants a CLS score under 0.1. This is often the easiest metric to fix and the one most teams ignore.

A page can score 100/100 in a lab test and still fail Core Web Vitals in the real world. Google ranks on field data from actual Chrome users — so test on a real phone, not just your fast laptop.

Why your site is probably slow

In our experience auditing dozens of sites, slowness clusters around the same handful of causes. If you only had an afternoon, you'd spend it here:

• Unoptimised images. A 3 MB hero JPEG is the single most common cause of bad LCP. Modern formats (WebP/AVIF), correct dimensions, and lazy-loading off-screen images often halve total page weight.
• Render-blocking scripts. Third-party tags — chat widgets, analytics, A/B tools, marketing pixels — load synchronously and freeze the main thread. Defer or async everything that isn't critical.
• Too much JavaScript. Shipping a 500 KB bundle for a brochure site is the classic INP killer. Send less code; split what you must send.
• No reserved space. Images and embeds without explicit width/height attributes cause layout shift every single load.
• A slow host or no caching. If your server takes 800 ms to respond before a byte is sent, no front-end fix will save you.

The fixes that reliably win points

None of these require a framework migration. In order of effort-to-payoff:

1. Compress and resize every image. Serve WebP or AVIF, set explicit width and height, and lazy-load anything below the fold. This usually fixes both LCP and a chunk of CLS at once.
2. Defer non-critical JavaScript. Add defer to scripts, load third-party tags after interaction where possible, and remove anything you're not actively using.
3. Preload the LCP element. Tell the browser about your hero image or font up front with <link rel="preload"> so it doesn't wait its turn.
4. Reserve space for everything. Dimensions on images, min-heights on ad and embed slots, and font-display: swap with a matched fallback to stop font swaps from shifting layout.
5. Cache aggressively and use a CDN. Static assets should be served from the edge with long cache lifetimes. This cuts both server response time and repeat-visit load.

How much does this actually move rankings?

Let's be honest: Core Web Vitals is a tiebreaker, not a magic wand. Relevance and content quality still dominate. But when you and a competitor are evenly matched, speed and stability tip the scale — and more importantly, a fast site converts better regardless of ranking. Faster pages mean lower bounce rates, more pages per session, and more completed checkouts. The SEO benefit is the bonus; the conversion benefit is the point.

So even if you treat Core Web Vitals purely as a user-experience exercise and ignore Google entirely, the work pays for itself. That's why we run a live PageSpeed audit on every project before and after launch — and why we built a free version of it into this very site.