The business case for a faster website

Customers never see a performance score. They see a product hesitate after a tap, a checkout button move while they are aiming for it, or an empty screen where the price should be. Each delay is small in isolation. Together they make the service feel less dependable, particularly when money or personal information is involved.

The gap between the development environment and the customer environment is usually substantial. A recent laptop on office Wi-Fi conceals expensive JavaScript, oversized media and slow third parties. Mid-range phones, warm CPUs and inconsistent mobile networks do not. Performance work has to begin with that less comfortable reality.

Choose one valuable path, landing page to enquiry, product page to checkout, or sign-in to a core task, and measure it on representative devices. Optimising the whole estate at once often produces a large backlog and little visible progress.

Start with field data where possible. Real User Monitoring shows the experience across actual devices, networks and locations, while laboratory tests make individual changes repeatable. Neither is sufficient alone: field data reveals impact, and controlled tests help identify the cause.

Performance competes with visible feature work, so the case must connect delay to commercial outcomes. Segment conversion, enquiry completion or activation by experience quality and device class. The purpose is not to claim that every slow visit causes a lost sale, but to identify whether poorer experiences consistently underperform after accounting for traffic source and intent.

Include acquisition efficiency in the calculation. If paid traffic reaches a page that is slow on the devices most customers use, part of the media budget purchases abandonment. A modest improvement across a high-volume journey can therefore be worth more than a dramatic improvement on a rarely visited page.

The usual gains are architectural: send less JavaScript, render useful HTML early, size media correctly and remove third-party scripts that do not justify their cost. Loading spinners and delayed widgets can hide latency, but they do not remove it.

Set performance budgets in delivery, not after launch. A budget turns speed from a one-off clean-up into a constraint that guides everyday product decisions.

Begin with what blocks useful content: server response, render-blocking styles, oversized hero media and client-side rendering that withholds the page until JavaScript runs. Then reduce main-thread work by splitting bundles, removing unused dependencies and delaying non-essential widgets until the visitor needs them.

Third-party scripts deserve the same scrutiny as first-party code. Analytics, chat, experimentation and advertising tools accumulate because each has an owner but their combined cost does not. Maintain an inventory with purpose, owner, loading strategy and expiry date, and remove anything that cannot justify its effect on the customer journey.

A budget is useful only when it changes a release decision. Set limits for transferred bytes, executable JavaScript, key user timings and third-party work, then run the checks in continuous integration. Keep the thresholds stable enough to identify real regressions; a test that fails randomly will be ignored within a sprint.

When a limit is exceeded, record the owner and the reason for accepting or correcting it. That small piece of governance turns performance from an annual clean-up into routine product engineering. Perfect scores are not the objective. A reliably responsive journey, maintained while the product evolves, is.