The real cost of a slow website (and the audit we run to fix it)

Most slow websites do not look broken. They look fine. Traffic arrives, the design holds up, nothing throws an error — and yet the enquiry form gets filled in less often than it should. The site is simply slow, and slowness is the one design flaw nobody screenshots.

This is the audit we run whenever a client says “it feels sluggish”, written out so you can run most of it yourself.

Where the seconds go

We always profile the same way: a real mid-range phone, throttled to 4G, with a cold cache. Not a desktop on office fibre — that configuration flatters every site ever built.

In practice almost all the wasted time falls into three buckets.

Images that were never processed. A hero photo exported straight from a camera or a stock library is routinely 2–4 MB. Converted to AVIF at the size it actually displays, the same image is often under 80 KB. This is usually the single biggest win available and it changes nothing visually.

A theme or framework bundle nobody trimmed. Page builders ship the code for every feature they offer, whether you use it or not. It is not unusual to find 800 KB of JavaScript on a page whose only interactive element is a mobile menu.

Third-party scripts loaded before anything renders. Analytics, chat widgets, heatmaps, ad pixels, a font service, a cookie tool. Each one is a request to somebody else’s server that happens before your visitor sees a word of your copy. Four of them is common. Four of them is also, frequently, a full second.

What we change

The fixes are unglamorous and they work in the same order every time.

• Render HTML first, JavaScript only where it earns its place. Most marketing pages need no client-side framework at all. The ones that do need it on a handful of components, not the whole document.
• Convert every image to AVIF with responsive sizes and lazy-load anything below the fold. srcset and sizes are doing the heavy lifting here — one image at one resolution is always wrong for somebody.
• Consolidate third-party scripts and load them after first paint. If a tool cannot tolerate being deferred, that is worth knowing before you commit to it.
• Serve from an edge CDN so the HTML renders close to the visitor rather than from one region.
• Subset the fonts. A variable font with the full glyph set is a large download for a site that only ever prints Latin characters.

Here is the shape of the image markup we end up with, which covers most of the win on its own:

<img
  src="vase.avif"
  srcset="vase-480.avif 480w, vase-960.avif 960w"
  sizes="(max-width: 600px) 100vw, 50vw"
  width="960"
  height="640"
  loading="lazy"
  decoding="async"
  alt="Hand-thrown ceramic vase"
/>

The width and height attributes matter more than people expect: without them the browser cannot reserve space, so the page jumps as images arrive. That jump is a Core Web Vitals failure in its own right.

How we measure it

Lab scores are a starting point, not the goal. We take three readings and we take them before touching anything, so there is a baseline to argue with later:

1. Lab: Lighthouse on a throttled mobile profile, run three times, median taken.
2. Field: the Core Web Vitals report in Search Console, which reflects your actual visitors on their actual devices. Lab and field disagreeing is normal and the field data wins.
3. Business: enquiry or checkout completion rate over the 30 days either side of the change.

The third one is the only number that pays for the work, and it is the one most performance reports quietly omit.

What to check on your site

You can do a useful version of this yourself in about ten minutes:

• Open your homepage on your phone, on mobile data, having force-quit the browser first. Count the seconds until you can read the headline. Anything over two is worth acting on.
• Run PageSpeed Insights and look only at the mobile tab and only at the field data panel if it is present.
• Open your browser’s network panel, sort by size, and look at the top five requests. If any of them is an image over 300 KB, you have found your afternoon.
• Count the third-party domains the page contacts. More than three is worth a conversation.

Speed is not a vanity metric. Faster pages rank better, convert better, and cost less to serve. If your site takes more than a second to show something useful, you are paying a tax on every visitor — and unlike most taxes, this one is refundable.