Why Your Website Speed Is Costing You Customers

Most businesses treat website performance as a technical detail, somewhere below colour schemes in priority. It isn't. It's one of the few things affecting your site that is simultaneously a ranking factor, a conversion factor, and a brand impression — and it's measurable, which is more than can be said for most marketing decisions.

The pattern is consistent across the industry: as load time climbs from one second toward five, the proportion of visitors who leave before the page finishes rises sharply. On mobile, on a suburban 4G connection, the effect is more pronounced still. You lose people before they have read a single word about what you do.

The numbers that matter

Google's Core Web Vitals are the useful shared vocabulary, partly because they map reasonably well to what users actually perceive.

LCP is usually the one to attack first — it's what people mean by "the site feels slow". CLS is the one that makes a site feel cheap, because content moves just as someone goes to tap it. INP matters most for anything interactive.

Measure these on a mid-range Android phone over a throttled connection, not on your laptop over office fibre. The gap between those two experiences is where most performance problems hide.

What actually makes sites slow

In our experience the causes are remarkably consistent, and rarely exotic.

Unoptimised images. By a wide margin the most common culprit. A 4MB photo straight off a camera, scaled down in the browser to 600px wide. The browser still downloads all 4MB. Modern formats and correctly sized variants routinely cut image weight by 70–90%.

Third-party scripts. Analytics, chat widgets, heat maps, ad pixels, A/B testing tools, embedded video players. Each one is a request to someone else's server, and each one can block your page. This is where "we only added one small tool" turns into two seconds of load time over a year.

Fonts. Custom web fonts are worth having, but loading six weights of three families, from a third-party domain, without a display strategy, will delay your text appearing and often cause a visible reflow.

Render-blocking resources. CSS and JavaScript in the document head that the browser must fetch and process before it can show anything.

Oversized JavaScript bundles. Shipping the code for the entire site to render the home page. Common in single-page applications that grew without anyone watching the bundle size.

No caching or CDN. Every visitor pulling every asset from a single origin server, potentially on the other side of the world from them.

Slow server responses. Unindexed database queries, chatty APIs, or shared hosting under load. If the server takes a second to begin responding, nothing you do in the browser will rescue the experience.

Fixes, in order of return

If you do nothing else, do the first three. They deliver the overwhelming majority of the improvement for a fraction of the effort.

1. Optimise and correctly size images. Serve modern formats such as WebP or AVIF, generate responsive variants so phones get phone-sized files, lazy-load anything below the fold, and always set explicit width and height attributes — that last one alone fixes most layout shift.
2. Audit third-party scripts ruthlessly. List every one. For each, ask what it's worth. Remove anything nobody has looked at in six months. Load whatever survives asynchronously, after the page renders.
3. Put a CDN in front of the site. Static assets served from an edge location near the visitor. This is cheap, often free at small scale, and effective immediately.
4. Self-host fonts, subset them, and use font-display: swap. Fewer weights than you think you need.
5. Split your JavaScript. Load what the current page requires, defer the rest.
6. Server-render or pre-render your pages. For content-driven sites, generating HTML at build time means the browser receives something meaningful immediately rather than waiting for JavaScript to construct it. This is exactly why this site is statically generated.
7. Fix the slow queries. If server response time is the bottleneck, nothing in the front end will compensate.

Automate it, or it will regress

Here's the part most teams miss. Performance isn't a project you complete — it's a property that decays. Someone adds a tracking pixel, someone uploads an unoptimised hero image, a dependency grows, and six months after your careful optimisation work the site is slow again.

The fix is to make performance a check rather than an initiative:

• Run automated performance tests in CI. Tools like Lighthouse CI can score every pull request and fail the build if key metrics regress.
• Set a performance budget. A hard limit on total page weight and JavaScript size. Exceeding it becomes a deliberate decision someone has to justify, not an accident.
• Monitor real users, not just lab tests. Synthetic tests from a data centre miss what your actual visitors experience on actual devices. Real-user monitoring shows you the long tail.
• Alert on regression. If LCP degrades past your threshold, someone should hear about it that week — not at the next quarterly review.

This is the same principle we apply to everything after launch: the work that keeps quality stable is automated and continuous, not heroic and occasional.

A fast site built once will be a slow site within a year. A fast site with a budget enforced in CI stays fast without anyone thinking about it.

What it's worth

Performance work is unusually easy to justify because the before-and-after is measurable.

A typical audit-and-fix engagement for a marketing site runs $4k–$12k and usually delivers most of its improvement through images, scripts and caching. For a complex application with a large JavaScript footprint, meaningful work is a larger exercise — often $15k–$40k — because it involves architectural change rather than configuration.

Against that, model the value. If your site converts at 2% and you improve that by even a tenth through a faster, steadier experience, the arithmetic usually resolves itself quickly. And unlike most marketing spend, the improvement persists.

Before you start

Get a baseline. Run your key pages through Google's PageSpeed Insights and note the field data — real Chrome user measurements — not just the lab score. Test on a real mid-range phone on mobile data. Look at your analytics for mobile bounce rate compared with desktop; a large gap is often a performance signal rather than a content one.

Then fix the top three things and measure again. Performance work is one of the few areas of software where the feedback loop is fast and the results are unambiguous.

---

Not sure whether your site is slow enough to matter? Send us the URL and we'll run it properly — real devices, real connections — and tell you what's costing you the most, and whether it's worth fixing.