Page speed is usually presented as a technical hygiene issue, somewhere between valid HTML and correct redirects. On pages that carry high-value enquiries, it is a commercial decision with a measurable cost.
The mechanism is not mysterious. A slow page loses a proportion of visitors before it renders, and the visitors it loses are disproportionately the ones on poor connections — which, in sectors like charter and construction, often means someone on a phone, on site or in transit, at exactly the moment they decided to act.
Where the time actually goes
- Images that were never resized for the layout they appear in.
- Fonts loaded from a third-party origin, blocking text on a connection that has to resolve a second DNS entry first.
- Analytics, chat, heatmaps and embeds — each individually defensible, collectively fatal.
- JavaScript shipped for interactions that ninety per cent of visitors never trigger.
None of these is exotic, and none of them requires an unusual engineering effort to fix. What they require is a budget that somebody enforces. A performance budget that nobody owns is a preference, and preferences lose to the next marketing tool every time.
Every third-party script is a decision to spend the visitor’s time. Somebody should have to justify it.
What we hold ourselves to
On the front ends we ship, the target is Largest Contentful Paint at or below 2.5 seconds on a mid-range mobile device and a throttled connection, interaction feedback visible within about 100 milliseconds, and cumulative layout shift under 0.1. Static delivery, self-hosted subset fonts, correctly sized images, and JavaScript sent only where an interaction genuinely needs it.
The honest caveat: speed alone does not sell anything. A fast page with an unclear proposition converts badly, just quickly. But a slow page loses people who had already decided to talk to you, and that is the most expensive kind of visitor to lose.