Why a fast website matters more than you think
Site speed isn't a technical nicety -it's directly tied to revenue, rankings, and trust. Here's what the data actually shows and what matters in 2026.
TillerLabs
Web design studio
Most businesses treat site speed as a technical detail -something to worry about if the developer mentions it, but not something to prioritise. That's a mistake. Speed is one of the very few things on a website that directly and measurably affects every metric you care about: ranking, conversion rate, bounce rate, and customer perception. Here's why, and what to actually do about it.
The three numbers Google cares about
Since 2021, Google has used Core Web Vitals as a direct ranking factor. There are three metrics:
- LCP -Largest Contentful Paint. How long until the main thing on the page appears. Target: under 2.5 seconds.
- INP -Interaction to Next Paint. How long from when the user taps something to when the page actually responds. Target: under 200ms.
- CLS -Cumulative Layout Shift. How much the page jumps around while loading. Target: under 0.1.
Google measures these using real-world data from Chrome users visiting your site. If your Core Web Vitals are poor, you're competing with a hand tied behind your back -every ranking signal has to work harder to compensate.
The conversion math
This is where it gets uncomfortable. Multiple large-scale studies from Google, Amazon, Walmart, and Deloitte have consistently found:
- A one-second delay in mobile load time can reduce conversions by around 20%.
- Pages that load in under 2 seconds have roughly twice the conversion rate of pages that load in 5+ seconds.
- Bounce rate roughly triples when load time goes from 1 second to 6 seconds.
For a local business doing, say, 30 enquiries a month, that's the difference between 30 and 15 per month, purely from technical speed -nothing else changed. Over a year, that's 180 lost enquiries. At even a modest close rate and average customer value, that's tens of thousands of pounds of revenue lost to a slow website.
What actually makes a site slow
Most slow sites are slow for a small number of specific, fixable reasons:
Huge images. A hero photo straight out of a camera can be 4MB. The same image, properly sized and converted to modern formats (WebP or AVIF), can be 150KB -26× smaller -with no visible quality difference. Most template sites never do this conversion.
Heavy JavaScript frameworks loaded for pages that don't need them. A marketing homepage does not need 500KB of React components to render five paragraphs of text. Proper modern builds (Next.js App Router, for example) ship far less JavaScript by default.
Too many third-party scripts. Every analytics tool, chat widget, social share plugin, and ad tracker you install adds 50–200ms to every page load. Most sites have 15+ of them. Most of those aren't doing anything useful.
Unoptimised fonts. Loading four font weights when you only use two. Loading fonts from Google Fonts instead of self-hosting. Not setting font-display to swap. Each of these adds visible delay on first paint.
Bad hosting. Cheap shared hosting routinely adds 500ms+ to every request compared to a modern platform. For small business sites, the hosting cost difference is usually £10/month at most.
What good looks like
A properly-built small business website in 2026 should:
- Load the main hero content in under 1.5 seconds on mobile 4G
- Be fully interactive within 2 seconds
- Weigh under 500KB on first load (including images, fonts, and code)
- Score 95+ on Lighthouse Performance for mobile
- Have green Core Web Vitals across LCP, INP, and CLS
This is achievable. It's not a stretch target -it's what you should expect from any builder who takes the craft seriously. If you're currently nowhere near those numbers, your site is costing you money every day.
The stack that makes this easy
The main reason TillerLabs sites score well on speed isn't that we're doing something magic -it's that we use a stack designed for it. Specifically:
- Next.js 16 for the application framework -ships minimal JavaScript, server-renders by default, handles images automatically
- Vercel for hosting -global CDN, Fluid Compute, sub-100ms response times from the closest edge
- next/image for automatic image optimisation -serves WebP/AVIF, correctly-sized versions per device, lazy-loaded by default
- next/font for fonts -self-hosted, preloaded, zero layout shift
- Tailwind CSS for styling -tiny production bundle, no runtime CSS-in-JS overhead
Using this stack, it's actually harder to build a slow website than a fast one. The defaults are sensible.
What to do if your current site is slow
Three options, in order of effort and cost:
1. The cheap fix: optimise images, remove unused third-party scripts, switch to better hosting. This can shave 50% off load time on many sites for under £200 of developer time. It's a patch, not a rebuild. 2. The proper fix: rebuild on modern tech. Typically 2–6 weeks, £2,000–£5,000. Pays for itself in months if your site has any meaningful traffic. 3. The wrong fix: install a "speed optimisation plugin" from your existing WordPress or Wix site. These almost always make things worse, or better by small amounts that don't move the needle.
The simple test
Plug your current website URL into PageSpeed Insights and look at the mobile score. If it's under 80, you're slow enough that it's costing you customers. If it's under 50, you're in trouble.
If you'd like a proper look at where your site stands -not just a Lighthouse score but a real breakdown of what's slowing it down and what it would cost to fix -request a free website health check and we'll send you one.