To improve website speed in practice comes down to three numbers: LCP, INP and CLS, together the Core Web Vitals. They decide not only how fast a page feels, but also how Google ranks your site and how many visitors leave before they have bought or requested anything. In this guide we explain those three values in plain language, show why speed costs or earns money directly, and give you a concrete checklist to fix it. For the full picture of a site that is fast from the foundation up, read our guide to commissioning a custom website.
What are Core Web Vitals exactly?
Core Web Vitals are three metrics Google uses to capture the user experience of a page in numbers. Not “does it feel fast”, but hard figures you can measure and improve. Since 2021 they have been an official ranking signal, and since 2024 INP is the third value instead of the old FID. The three are:
- LCP (Largest Contentful Paint): how long does it take until the largest element on screen has loaded? Usually your hero image, a big heading or a video thumbnail. This is your perceived load time.
- INP (Interaction to Next Paint): how fast does the page respond when a visitor clicks, taps or types? This measures whether your site “hangs” on interaction.
- CLS (Cumulative Layout Shift): how much does the layout jump while loading? Think of a button that moves the moment you go to click it, because an ad or image shoves in above it.
The official definitions and measurement methods live on web.dev from Google, the canonical source for these metrics. Worth knowing: Google measures these vitals with real visitor data from Chrome, not with a lab test. So your own fast laptop on office internet tells you very little about what your visitors experience on mobile.
Which values are good, and when are you in the red zone?
Google sorts each metric into three zones: good, needs improvement, and poor. You want to sit in the green zone on all three vitals, measured at the 75th percentile of your visitors (so three out of four visitors experience at least this value). Below are the thresholds that apply in 2026.
| Metric | Good | Needs improvement | Poor (red zone) |
|---|---|---|---|
| LCP (load speed of largest element) | under 2.5 sec | 2.5 to 4.0 sec | above 4.0 sec |
| INP (response to interaction) | under 200 ms | 200 to 500 ms | above 500 ms |
| CLS (visual stability) | under 0.1 | 0.1 to 0.25 | above 0.25 |
A few things stand out the first time you see this. LCP is a time in seconds and usually the hardest to get green, certainly on a slow mobile connection. INP is measured in milliseconds and is mostly a problem on sites with a lot of JavaScript. CLS is not a time but a ratio: 0 is perfectly stable, anything above 0.25 feels like a jumpy page. For most SMB sites we see LCP as the biggest challenge, simply because the hero image is too heavy or the hosting is too slow.
Why does a slow website cost you money?
Speed is not a technical nice-to-have, it is a direct lever on your revenue. That sounds like sales talk, but it is measurable and large companies have backed it up for years. The logic is simple: the longer a page loads, the more people click away before they have seen anything at all. And whoever clicks away buys nothing and requests nothing.
The figures that keep coming back in research from Google and large retailers:
- A load time that climbs from 1 to 3 seconds sharply raises the chance someone bounces. From 1 to 5 seconds more than doubles that chance.
- For webshops, every 100 milliseconds of speed gain translates into measurably higher conversion. At serious revenue volumes that quickly runs into thousands of euros per month.
- Slow sites rank lower in Google, which means less organic traffic. Less traffic plus lower conversion is a double hit.
There is a second effect owners often forget: speed affects your whole website, not just the homepage. Every product page, every landing page and every form counts. A slow checkout is more lethal than a slow homepage, because that is where the visitor already has their wallet in hand.
What makes a website slow?
Before you optimise anything, you need to know where the delay comes from. In practice, 90 percent of slow sites come down to four causes, often in combination. Below are the culprits in order of how often we run into them on SMB sites.
| Cause | What it does | How often we see this |
|---|---|---|
| Heavy images | Uncompressed photos of several MB slow LCP enormously | Almost always |
| JavaScript bloat | Too many scripts, trackers and libraries block INP and rendering | Very often |
| Slow or cheap hosting | Server responds slowly, high time-to-first-byte | Often |
| Too many plugins (WordPress) | Each plugin loads its own CSS and JS, even when unused | Often (on WordPress) |
| No caching | Every visitor gets a freshly built page | Regularly |
| Render-blocking resources | CSS and fonts that hold up drawing the page | Regularly |
The biggest single win is almost always in the images. An unoptimised 4 MB hero photo that could have been 400 KB is two to three seconds of LCP gain on mobile, straight away. After that comes JavaScript: trackers, chat widgets, A/B-test scripts and heavy page builders pile up into a mountain the browser has to chew through before the page responds. According to the HTTP Archive Web Almanac, the amount of JavaScript an average page ships has been climbing for years, and that is exactly where INP problems come from.
How do I improve my website speed? The checklist
Below is the approach we follow in practice, from quick wins to deeper work. You can often do the first four points yourself, the rest usually needs a developer. Work top to bottom, because the top items deliver the most gain per hour of work.
- Compress and convert your images. Convert everything to a modern format (WebP or AVIF), scale to the actual display size, and lazy-load everything below the fold. This alone often shaves a full second off your LCP.
- Turn on caching. A caching layer serves visitors a ready-made page instead of rebuilding it every time. On WordPress you do this with a plugin, on a static site it is the default.
- Clean up your plugins and scripts. Drop every plugin you do not actively use. Remove duplicate trackers. Ask yourself whether that chat widget and those three analytics scripts really need to load on every page.
- Use a CDN. A Content Delivery Network serves your site from a server close to the visitor. For Dutch visitors that saves tens of milliseconds, for international traffic much more.
- Trim render-blocking CSS and fonts. Load only the CSS the page needs immediately, and load fonts with
font-display: swapso text is visible right away. - Reserve space for dynamic elements. Give images and ads fixed dimensions so the layout does not jump. This is the direct fix for a poor CLS.
- Consider a faster architecture. If your site stays structurally slow, the problem is usually the foundation. A static or server-rendered approach is then the real fix, not yet another plugin.
Point 7 is where many sites eventually get stuck. You can take a slow WordPress site with plugins and caching a long way, but there is a ceiling. A site built on modern techniques like Astro ships almost no JavaScript by default and scores green on all three vitals nearly automatically. The trade-off between those foundations sits in our comparison of Astro, Next.js and WordPress.
Why is a static website almost always faster?
A traditional WordPress site rebuilds every page the moment a visitor requests it: it queries the database, runs PHP, gathers the plugins and assembles the HTML. That takes time, certainly on shared hosting. A static site does that work once up front, at build time, and then serves a ready-made HTML file. The server only has to send a file.
The difference is large. With a static approach the time-to-first-byte is often under 200 milliseconds, the page ships minimal JavaScript (which keeps INP low), and hosting is cheaper because there is no heavy server to run. This is exactly why we default to Astro for most marketing sites and webshops with manageable catalogues. The flip side: for strongly interactive, logged-in applications with real-time data, a static approach is not the right choice, and you pick a server-rendered framework instead. The trade-off depends on how dynamic your site really is, not on the hype around a tool. The MDN Web Docs are a solid reference if you want to understand how these rendering models differ under the hood.
For the visual design that sits on top of this, we work from a webdesign that does not get in the way of speed. A beautiful site that is slow is not a beautiful site.
How do I best measure my Core Web Vitals?
There are two kinds of measurement, and the difference matters. Lab data comes from a simulated test (like Lighthouse) and is handy for quick diagnosis. Field data, also called real visitor data, comes from actual users and is what Google actually ranks on. Steer on the field data, use the lab data to track down problems.
| Tool | Type of data | Best for |
|---|---|---|
| PageSpeed Insights | Lab plus field | Quick diagnosis per page, free, concrete tips |
| Google Search Console | Field (real data) | Overview of all pages, this is what counts for ranking |
| Chrome DevTools (Lighthouse) | Lab | Digging deep during development |
| web-vitals library | Field | Continuous measurement in your own analytics |
For most owners, the combination of PageSpeed Insights for individual pages and Google Search Console for the full picture is enough. Search Console shows per URL group which pages score green, orange or red on real visitor data, and that is exactly the signal your ranking hangs on. The official measurement guidelines and the accompanying explanation are on Google Search Central.
What if my site is still slow after all the optimisation?
Sometimes you hit a ceiling. You have compressed images, caching on, plugins cleaned up, and still LCP stays stuck at 3.5 seconds. That is the moment to look honestly at the foundation instead of at the tenth plugin. Three common causes that no quick fix can solve:
- The hosting is structurally too slow. Cheap shared hosting shares a server with hundreds of other sites. A better hosting environment or a static deploy fixes this, not another caching plugin.
- The theme or page builder is too heavy. Some WordPress themes and builders ship so much CSS and JavaScript that no optimisation gets them green. Here, only a lighter foundation helps.
- The architecture does not fit the goal. A content site built as a heavy application, or the other way around. This is a rebuild question, not an optimisation question.
At that point, polishing further is a waste of your time and money. Often a rebuild on a fast foundation is cheaper than keeping tinkering at a slow one for two years. When you weigh that up, watch the quiet costs of a cheap foundation, because they rarely show up in the first quote. We do that math in our guide to the hidden costs of cheap websites.
What is the first step?
Improving speed does not have to be a months-long project. Start small and measure your progress.
- Step 1: measure your three most important pages. Homepage, your main landing page and your checkout or contact form. Run them through PageSpeed Insights and note LCP, INP and CLS.
- Step 2: grab the quick wins. Compress the heaviest images, turn on caching and drop unused plugins. Measure again and see the difference.
- Step 3: decide on the foundation. If you are still red or orange after the quick wins, the problem sits deeper. Then it is time for an honest conversation about the architecture.
Book a free intro call if you want us to take a look at your scores. No sales pressure, just a grounded view on where the biggest win sits. For the full picture of a site that is fast from the foundation, read our guide to commissioning a custom website and see what we build on our development page.
