The real cost of a slow website

Nobody emails to say your site is slow. They just leave. That is what makes performance a difficult problem to prioritise: the cost is real and continuous, but it never arrives labelled as a website issue. It arrives as a quiet month, a rising ad cost, a support inbox full of people who could not find something obvious.

Where the money actually goes

Paid traffic you have already bought. If you spend on ads, every second of load time is spend you have committed to and not collected on. A visitor who bounces before first paint cost you exactly as much as one who converted. This is usually the largest single line, and the easiest to quantify: take your monthly ad spend, multiply by your landing-page bounce rate above the industry norm, and you have a floor for the number.

Organic visibility. Core Web Vitals are a ranking signal. They are not the strongest one, but they act as a tiebreaker in exactly the competitive positions where a tiebreaker decides the click. Worse, slow pages get crawled less, so new content takes longer to appear at all.

Conversion rate, across the whole funnel. The effect compounds: a slow product page loses browsers, a slow cart loses buyers, and a slow checkout loses people who had already decided to pay you. The last of those is the most expensive traffic on the site.

Internal time. A slow admin is a tax on every content update, every order lookup, every price change. It rarely gets counted, and it is often the thing your team notices first.

The three causes we find, over and over

Hosting configured for the sales page, not the workload

Shared hosting is fine until it is not. The failure mode is not a crash; it is inconsistency — fast at 9am, unusable at 8pm, and no obvious pattern. If your time-to-first-byte moves by more than a few hundred milliseconds across the day, the problem is under the application, and no amount of front-end optimisation will fix it. We have moved sites where a hosting change alone cut load time by more than half, with not one line of code touched.

Images shipped at the wrong size

Still the most common single cause. A camera-resolution JPEG dropped into a card that renders at 400 pixels wide is a multi-megabyte download for a thumbnail. Serve WebP or AVIF, generate the sizes the layout actually uses, and lazy-load everything below the fold — with the deliberate exception of the hero image, which should load eagerly and with high priority.

Plugins loading everywhere

A typical WordPress site loads assets from every active plugin on every page, whether that page uses them or not. The contact form’s JavaScript on the homepage. The gallery library on a text page. Each one is small; together they are the difference between a page that feels instant and one that feels like work.

What “fast enough” means

Aim for these on a mid-range phone over 4G, not on your desktop over office fibre:

• Largest Contentful Paint under 2.0s — the main content is visible.
• Cumulative Layout Shift under 0.05 — nothing jumps as it loads.
• Interaction to Next Paint under 200ms — taps respond immediately.

Measure with field data where you can. Lab tests on a fast connection will tell you your site is fine long after your customers have concluded otherwise.

The uncomfortable part

Most performance work is not clever. It is removing things: a plugin that duplicates a feature you already have, a font weight nobody uses, a tracking script from a tool you stopped using two years ago. The clever work — critical CSS, edge caching, database tuning — comes after, and matters less than people expect.

If you only do one thing this quarter, run your three highest-traffic pages through a field-data check and fix whatever the largest single contributor turns out to be. It is almost never what you assumed.