Why website speed matters

Visitors leave slow sites, and Google measures speed directly (the Core Web Vitals) and uses it in ranking. But "make it faster" is useless advice without knowing what makes a site slow in the first place. Here is what we actually find when we look, roughly in order of how often.

What Google measures

Three numbers, taken from real visitors' browsers: Largest Contentful Paint (how long until the main content is visible — aim under 2.5 seconds), Interaction to Next Paint (how quickly the page responds when tapped — under 200 ms), and Cumulative Layout Shift (how much things jump about while loading — under 0.1). You can see your own site's scores free in PageSpeed Insights or Google Search Console, and they are measured on phones on ordinary connections, not on your office fibre.

What actually makes sites slow

1. Images that are far bigger than they need to be

The most common problem by a mile. A 4,000-pixel photograph straight off a phone, displayed 400 pixels wide, is a 3 MB download to show a thumbnail. Fix: resize to the size actually displayed, serve modern formats (WebP, AVIF), and let the browser choose the right size for the screen (srcset). Every site we build does this automatically through an image pipeline; on most other sites it's done by hand or not at all.

2. Page-builder and theme bloat

Drag-and-drop builders ship every feature they have on every page, whether the page uses it or not: hundreds of kilobytes of scripts and styles for a slider you deleted. It is the reason a simple five-page site can weigh more than a newspaper's homepage. Fix: a site built by hand loads only what the page needs — which is the single biggest reason ours are quick.

3. Third-party scripts

Chat widgets, analytics, tag managers, social embeds, fonts from a CDN, cookie banners — each one is a separate connection to a separate server before your page is complete, and some of them block rendering. Fix: keep only what earns its place, load it after the content, and host fonts yourself.

4. Slow hosting and no caching

If the server takes a second to start sending the page ("time to first byte"), nothing else you do matters much. Cheap shared hosting with a busy neighbour, or a site that rebuilds every page from the database on every request, both cause it. Fix: sensible hosting, page and object caching, and a CDN in front of static assets.

5. Layout that jumps

Images without dimensions, fonts that swap after loading, banners that push content down — each one is a layout shift, and Google counts them. Fix: reserve space for images and adverts, use font-display sensibly, and don't inject things above the fold after load.

6. Doing the work on the visitor's phone

A page that arrives as an empty shell and then builds itself in JavaScript makes a low-end phone do the work a server should have done. Fix: send real HTML for the content, keep scripts small, and treat a four-year-old Android on 4G as the target, because for many of your customers it is.

How to check your own site

What "fast" looks like

A page under about a megabyte, main content visible in under two seconds on a mid-range phone, no jumping, and a PageSpeed performance score in the 90s on mobile. That is the target for every site we build, and it's achievable for any small-business site — it just has to be built with it in mind rather than optimised afterwards.

Quick answers