Improving Core Web Vitals: what to do when your website is too slow

"The website feels slow" — we hear that a lot, usually paired with the worry that it's why Google isn't going the way you'd hoped. The good news: speed isn't a gut feeling, it's measurable. Google bundles the most important metrics under the name Core Web Vitals. In this article we'll explain what's behind them, why the numbers matter for rankings and conversion, how to measure them yourself — and which bottlenecks are most often to blame in practice.

In our article on technical SEO basics we only touched on speed briefly. Here we go deep on purpose: concrete, with numbers and ways to fix things, but understandable enough that you as a decision-maker can join the conversation — not just your developers.

What are Core Web Vitals — in one sentence?

Core Web Vitals are three metrics Google uses to measure how fast, how responsive and how stable your website feels to real visitors. So it's not about abstract technology, it's about the actual user experience: how long am I staring at a blank page? Does it react when I click? And does the layout jump around while I'm trying to read?

The three values are called LCP, INP and CLS. Let's look at them one at a time.

LCP — how fast is the content there?

LCP (Largest Contentful Paint) measures how long it takes for the largest visible block of content to load — usually the main image or the headline at the top. Put simply: the moment the visitor feels "okay, the page is here now".

• Good: under 2.5 seconds
• Needs improvement: 2.5 to 4 seconds
• Poor: over 4 seconds

Typical bottlenecks are a huge, uncompressed header image, a slow server that takes forever to respond at all, or render-blocking files that hold up loading. LCP is usually the metric where you can make the most visible difference.

INP — does the page respond to me?

INP (Interaction to Next Paint) measures how quickly the page responds to input — clicks, taps, keystrokes. You know the feeling: you click a button and nothing happens for what feels like an eternity. That's exactly what INP makes measurable. This metric replaced the older FID (First Input Delay) in 2024 and is stricter, because it looks at responsiveness across the entire visit.

• Good: under 200 milliseconds
• Needs improvement: 200 to 500 milliseconds
• Poor: over 500 milliseconds

The culprit here is almost always too much JavaScript blocking the browser while it should be responding to the user. Overloaded pages with a dozen tracking scripts and heavy plugins are the usual suspects.

CLS — does the layout stay stable?

CLS (Cumulative Layout Shift) measures how much content jumps around while loading. Everyone knows it: you're about to tap a link, at the last moment a banner loads, everything slides down — and you click the ad. CLS isn't a time value but a score that rates these shifts.

• Good: under 0.1
• Needs improvement: 0.1 to 0.25
• Poor: over 0.25

The causes are images without fixed dimensions, ads or banners loading late, and fonts that reflow after the fact. CLS is often fixable with little effort — and the effect on how the site feels is enormous.

Why these numbers matter for rankings AND conversion

Here's the point that makes this relevant for every decision-maker: Core Web Vitals work on two levels.

For rankings: Google uses the user experience (the "page experience") as a factor. Between two pages with comparable content, the faster one often tips the scale. Poor numbers are rarely the sole reason for a drop — but they're a drag you can afford to remove.

For conversion: and that's usually the bigger lever. Every extra second of load time measurably costs you visitors who simply bounce before the page is even there. People who wait don't buy, don't book, don't send an inquiry.

Put differently: you're not improving these numbers for Google, you're improving them for your customers. That Google rewards it is the pleasant side effect.

How to measure your Core Web Vitals — for free

Before you optimize anything, you need numbers. Otherwise you're turning knobs blind. These tools are free and good enough for a first, honest assessment:

• PageSpeed Insights (from Google): you enter your URL and get all three values — from both real user data and a lab test — plus concrete suggestions for improvement.
• Google Search Console: the "Core Web Vitals" report shows how many of your pages fall into the green, yellow or red range — across the whole website, not just a single page.
• Lighthouse (built into the Chrome browser): for a quick test of individual pages straight from the browser.

The most common bottlenecks — and how to fix them

In our projects it's the same culprits over and over. The good news: most of them can be fixed deliberately.

1. Images that are too large. The classic. A 4 MB photo straight from the camera that the browser shrinks to postage-stamp size. Fix: serve appropriate sizes, use modern formats like WebP, compress. That alone often rescues the LCP.
2. Too much JavaScript. Every tracking tool, every chat button, every plugin brings code that wants to be loaded and executed. Fix: clear out what nobody uses, and load the essentials later (deferred).
3. Render-blocking files. Scripts and stylesheets that hold up displaying the page even though they're only needed later. Fix: critical content first, the rest asynchronously.
4. A slow server or no caching. When the server recalculates everything on every request instead of caching finished results, time is lost before anything reaches the visitor at all. Fix: caching, fast hosting, a CDN where it makes sense.
5. Layout shifts from missing dimensions. Images and embedded elements without a fixed width and height don't reserve space — so everything slides as soon as they load. Fix: set the dimensions so the space is there from the start.

The order isn't accidental: we always work by impact. The measure that helps most first, instead of getting stuck on details.

Does this mean rebuilding the whole website?

Usually not. On a lot of sites you get the biggest jumps from manageable interventions — optimize images, clean up scripts, switch on caching. That's often a matter of days, not weeks.

But we want to stay honest too: when a website sits on a sluggish foundation — an overloaded system, a theme with dozens of plugins, slow hosting — pure cosmetics eventually hits a wall. Then it's more honest to say that a technical rebuild pays off more than patching forever. What makes sense in your case only becomes clear once you've measured.

Our takeaway

Core Web Vitals sound technical, but at their core they're a simple question: does your website feel fast, responsive and stable? If not, it's costing you visitors and visibility — and both can be measured and improved deliberately. The nice thing is exactly that measurability: you see what's stuck beforehand, fix it, and check the result afterwards. No guessing, no flying blind.

You've got the feeling your website is too slow but don't know why? We'll measure your Core Web Vitals, show you in plain language which bottlenecks cost the most, and tell you honestly whether a few targeted fixes are enough or more is needed. Let's take a look together in a free initial call — no obligation and no jargon.

Frequently asked questions