How Website Speed Costs You Sales (And the 2026 Fix List)
Slow sites still cost businesses money. The 2019 fix list is broken. Core Web Vitals in plain English, modern tools, and the fixes that move the needle.
A 0.1-second improvement in mobile load time lifts retail conversions by 8.4%. That stat is from a Google, fifty-five and Deloitte study published in May 2020. Six years on, it's still rarely acted on.
The case for caring about site speed hasn't changed. The instructions for doing something about it have. Most of the advice you'll find when you search "how to speed up my website" was written before Core Web Vitals existed. It recommends tools that don't matter anymore and skips the metrics Google actually ranks on.
This is the 2026 fix list. It's pitched at marketing leads and business owners who suspect their site is slow but don't speak the language. By the end you'll be able to (a) make the business case to a sceptical boss, (b) describe the three metrics that matter in plain English, (c) know which tool to point at the problem first, and (d) hand a developer a prioritised list of fixes ordered by likely impact.
The 2026 business case
The numbers behind the original Milliseconds Make Millions study are blunt. A 0.1-second mobile improvement lifts retail conversions by 8.4% and average order value by 9.2%. Travel conversions move up 10.1%. Luxury sites see page views per session rise 8.6%.
Akamai's research puts it the other way around. A 100-millisecond delay can drop conversion rates by 7%. A two-second delay roughly doubles bounce rate.
The compounding factor in 2026 is search. Page Experience (which includes site speed) has been a Google ranking signal since 2021, and Google has continued to refine its weighting through 2025 and 2026. Slow sites lose conversions on the visit and lose visibility in the first place. That's a double tax most owners never connect.
Speed alone won't outrank a competitor with much stronger content. But when two sites are evenly matched, the faster one wins more of the close calls. Every close call lost to slowness is one your content already paid to win.
What's actually being measured: Core Web Vitals in plain English
Core Web Vitals
Google's three real-user-experience metrics, scored from anonymous Chrome data and reported per page. To pass, 75% of real visits to a page need to score "good" on all three.
CWV replaced the old "page speed" mental model in 2021. Where the 2019 advice talked about loading time as one number, Google now measures three different things, each tracking a distinct part of the experience. You need to clear all three thresholds, not just the average.
LCP (Largest Contentful Paint)
Largest Contentful Paint
How long it takes for the biggest visible element on the page to appear. Usually the hero image, the hero video, or the main headline.
Threshold: under 2.5 seconds is "good". 2.5 to 4.0 seconds is "needs improvement". Over 4.0 seconds is "poor".
LCP is the metric most owners intuitively understand. If LCP is bad, the page feels slow before the user can do anything.
INP (Interaction to Next Paint)
Interaction to Next Paint
How long the page takes to respond to a click, tap, or key press. Measures every interaction across the page's life, not just the first one.
Threshold: under 200ms is "good". 200 to 500ms is "needs improvement". Over 500ms is "poor".
INP replaced FID (First Input Delay) as a Core Web Vital on March 12, 2024. It's a tougher metric. FID only looked at the first interaction. INP looks at all of them and reports the worst at the 75th percentile.
Industry analyses of the public CrUX dataset suggest around 43% of sites still fail INP. It's the most commonly failed Core Web Vital in 2026, and it's the one that's hardest to retrofit, because the cause is almost always JavaScript that someone bolted on years ago.
CLS (Cumulative Layout Shift)
Cumulative Layout Shift
How much the page jumps around as it loads. The button you were about to tap moves, an ad slot pops in, an image appears and pushes the text down.
Threshold: under 0.1 is "good". 0.1 to 0.25 is "needs improvement". Over 0.25 is "poor".
Small CLS scores ruin trust quickly. Users learn not to tap anything until the page stops moving, then they navigate away before they bother.
If you remember nothing else from this section: under 2.5 seconds, under 200 milliseconds, under 0.1. That's the bar.
How to know if you have a problem
Start with PageSpeed Insights. Paste your URL in, click run, look at the field-data tab. Field data is what real Chrome users saw over the last 28 days. Lab data is what Google saw in a synthetic test on a standardised device. Real data is what counts for ranking.
- PageSpeed Insights (pagespeed.web.dev).Start here. Real-user field data plus a prioritised list of opportunities, in one screen.
- Search Console, Core Web Vitals report.Best for diagnosing site-wide patterns. Groups URLs by failing metric and shows trend over time.
- Lighthouse (Chrome DevTools, F12 then Lighthouse tab).For testing changes locally before deploy. Lab data only.
- CrUX dashboard (Chrome User Experience Report on Looker Studio).The underlying dataset Google uses. Useful for stakeholder reporting.
The 2026 fix list, prioritised by impact
These are ordered by the size of impact they usually have on a typical small-to-mid-sized business website. Work top-down. Don't jump to fix five before you've checked the obvious wins in fix one and two.
Get a CDN in front of your site (LCP + INP)
A CDN (Content Delivery Network) is a network of edge servers that cache your pages and assets close to the user, cutting the distance the data has to travel. That reduces TTFB (time to first byte) by 50 to 200 milliseconds for most sites. A real LCP improvement before you've changed anything else.
Cloudflare's free tier is enough for most SMB sites. Vercel, Netlify and modern Webflow plans ship a CDN by default. If you're on WordPress with a cheap shared host and no CDN in front of it, this is the move. It's the single biggest win for sites under 100,000 monthly visits.
Modernise your image formats (LCP)
The biggest LCP killer in the wild is oversized images. Owners and marketing teams upload full-resolution photos straight from a camera, phone, or stock library, and those 3-to-5 MB files load on every page view.
Serve AVIF first, WebP as fallback, original format last. Modern WordPress, Webflow, Shopify and Next.js can all do this automatically. Turn the setting on. Set explicit width and height attributes on every image, because that also fixes CLS later.
Defer non-critical JavaScript (INP)
The biggest INP killer is third-party JavaScript blocking the main thread. Tag managers, marketing pixels, chat widgets, analytics, A/B testing tools. Audit what's actually running. Defer or async every script that isn't needed for the page to render. Load chat widgets only after the user scrolls past the fold.
If a script is "essential" but it's slowing every page, push back on whoever told you it's essential. Half the time it's running on pages that don't need it.
Self-host your fonts and use font-display: swap (LCP + CLS)
Calling Google Fonts via the CDN URL has a third-party DNS lookup baked in. Self-host the woff2 files instead, preload the two or three weights you actually use, and set font-display: swap so text appears in a fallback font while the web font loads. That stops the "invisible text for 1.2 seconds" pattern.
Reserve space for everything dynamic (CLS)
Width and height on every image. Width and height on every iframe. Skeleton placeholders for ad slots. CSS aspect-ratio for video embeds. The rule: anything that loads after the initial paint needs reserved space, otherwise it shoves the surrounding content around when it arrives.
Cache aggressively (LCP)
If you're serving the same HTML to every visitor, cache it. On WordPress that means a real caching plugin like WP Rocket, or LiteSpeed Cache where available. On a headless setup that means page-level cache headers plus CDN edge caching. The goal is to never re-render the same page twice if the content hasn't changed.
Audit your CMS and theme bloat (LCP + INP)
The slowest WordPress sites we audit usually have 30 or more plugins active, half of which are bundling their own jQuery. Themes that ship with a built-in page builder (Elementor, Divi, WPBakery) add 200 to 500 KB of CSS and JS to every page. Trim plugins ruthlessly. Switch to a lean block-based theme. Audit page-builder usage on the high-traffic pages first.
Don't deactivate plugins randomly. Measure before and after each change with PageSpeed Insights' lab data. The plugin you suspect is rarely the one actually causing the slowdown.
What to stop bothering with (2019's advice that aged out)
A short detour, because half the advice you'll find on this topic is six years out of date and still being copy-pasted into agency blog posts.
Gzip compression doesn't need its own todo anymore. Modern CDNs and web servers default to Brotli or Zstandard, both of which beat Gzip. If your Content-Encoding header says anything modern, you're fine.
Minifying CSS and JS manually is also a non-issue on modern stacks. Vite, Next.js, esbuild and the rest minify production builds automatically. If you're shipping unminified production code, the problem is upstream in the build pipeline, not in a "minifier plugin" you forgot to install.
Desktop image compression tools like Kraken, ShortPixel desktop and ImageOptim were the answer in 2019. In 2026 the answer is automatic AVIF and WebP conversion at the CMS or CDN layer. Don't compress before upload. Let the platform handle it.
"Upgrade to a VPS" was the right answer when £4-a-month shared hosting was the baseline. In 2026 the upgrade is a managed platform like Vercel, Netlify, WP Engine or Cloudways, with edge caching, automatic image optimisation and a real CDN bundled in.
GTMetrix as your primary diagnostic isn't wrong, but it's not the scoreboard. PageSpeed Insights uses Google's own CrUX data, which is what Google ranks on. Use the tool that matches the scoreboard.
When to call in a developer
Most owners can run PageSpeed Insights themselves and pick up the obvious wins: a CDN, image format updates, a plugin audit. Those three alone often move a site from failing two CWV to passing two.
Anything past that needs a developer who's done this before. INP fixes that require JavaScript profiling. Server-side rendering changes. Theme rewrites. The red flag to listen for is "we'll redesign the whole site" as the answer to "my LCP is 3.2 seconds". That's rarely the right answer. The right answer usually starts with a CDN, an image audit and a JavaScript audit, in that order.
What to ask for: a Core Web Vitals audit that names the failing metric per template (home, product, blog post, etc.), the specific cause, and the fix ranked by effort versus expected score improvement. If they can't write that one-page brief, they haven't done it before.
FAQ
What's a good page speed?
Under 2.5 seconds for Largest Contentful Paint, under 200 milliseconds for Interaction to Next Paint, and under 0.1 for Cumulative Layout Shift. That's the bar Google measures against, and 75% of your real visitors need to clear it for the page to pass.
How do I check if my site has a speed problem?
Start with PageSpeed Insights (pagespeed.web.dev). Paste your URL, click run, look at the 'field data' tab. That's the real-user score Google uses for ranking. If it's red on any of LCP, INP or CLS, you have a problem.
Will faster pages actually rank higher?
Page Experience (which includes Core Web Vitals) has been a Google ranking signal since 2021, and Google has continued to refine its weighting through 2025 and 2026. Speed alone won't beat a competitor with much stronger content, but slow sites are increasingly losing the close calls.
Does INP really matter?
Yes. INP replaced First Input Delay (FID) as a Core Web Vital in March 2024, and industry analyses of public CrUX data suggest around 43% of sites still fail its 200-millisecond threshold. It's the most commonly failed CWV right now, and the one most likely to be silently dragging your site.
Is 'site speed' the same as 'page speed'?
Functionally yes. Both refer to how fast individual pages load and respond. Google measures the experience per page, not site-wide, so a slow homepage and a fast blog post are scored separately.
How long does it take to fix a slow site?
A CDN plus image compression pass takes a day. JavaScript audits and INP work take one to three weeks. Full theme or architecture rebuilds take longer than that. Most SMB sites can pick up two CWV passes inside two weeks of focused work.
The TL;DR
The link from speed to revenue is real, the modern measure is Core Web Vitals (LCP, INP, CLS), and the diagnostic floor is PageSpeed Insights. Most sites pick up two CWV passes from a CDN, an image fix and a JavaScript audit. The fixes compound. A faster site converts better, ranks better, and earns more trust on first impression.
If your site's slow and you've been putting this off, the cost is already being paid. It's just been silent.