Site speed is treated as a technical nicety. Priced properly, it is usually one of the largest line items on the site.
Nobody argues that a fast site is worse than a slow one. The trouble is that speed is discussed as a quality — like tidiness — rather than as a number with money attached, so it never competes successfully for budget.
Treated as a ranking factor it is a weak argument, because it is a modest one. Treated as a conversion factor it is one of the strongest arguments available, because it affects visitors you have already acquired and already paid for.
Put a figure on it
Take your mobile traffic, your current bounce rate on the slowest templates, and your average value per session. The difference between your current performance and a realistic target is a number you can take to a budget meeting.
It is usually larger than people expect, because the loss is concentrated exactly where it hurts: mobile visitors arriving from paid campaigns you have already paid for. Every one of those sessions was bought at auction. Losing a fifth of them to a four-second load is a discount on your entire media budget.
You do not need precision. A range with the assumptions stated beats an exact figure nobody believes, and it survives the inevitable challenge from someone who thinks the number looks too big.
The usual culprits
In our experience it is rarely exotic. Uncompressed hero imagery, a third-party script loaded in the head that blocks rendering, a font stack that reflows the page after it paints, and a tag manager quietly carrying six vendors nobody has audited in two years.
Images are almost always first and almost always the cheapest to fix: correctly sized, served in a modern format, with explicit dimensions so the layout does not jump while they load. This is a build-pipeline change rather than a redesign.
The tag manager is worth checking today. Most sites are paying a performance cost for tools that were switched off long ago but never removed — a heat-mapping trial from 2023, a chat widget from a campaign that ended, two analytics packages where one would do.
Measure what visitors experience, not what a tool reports
A synthetic score from a testing tool is a diagnostic, not a result. It runs on a simulated device on a good connection and tells you what could be improved; it does not tell you what your visitors are actually experiencing on the handsets and networks they really use.
Field data is the number that matters — real measurements from real sessions, segmented by device and template. A site can score respectably in the lab and still be slow for the third of visitors on older Android handsets, which is precisely the segment where the revenue is leaking.
Speed is now a visibility problem too
Beyond conversion, slow and script-dependent pages are harder for crawlers to process, and AI crawlers in particular frequently do not execute JavaScript at all. Content that only exists after hydration may simply not be seen by the systems increasingly answering your buyers’ questions.
That makes performance work part of technical SEO rather than a separate engineering concern, and it raises the return on doing it properly.
Build so it stays fast
A one-off optimisation decays. Six months after a speed project, someone adds a video background, someone else adds a personalisation script, and the site is back where it started with nobody having made an obviously wrong decision.
Performance holds when there is a budget in the build process that fails when the page gets too heavy, so the regression is caught before launch rather than discovered a quarter later. It is a small amount of engineering work that removes the need to have this argument again.
Common questions
- How fast should a website be?
- As a working target, aim for the main content to render within about 2.5 seconds and for the page to be interactive shortly after, measured on a mid-range mobile device on a typical connection rather than in a lab. The more useful test is comparative: how do your slowest templates convert against your fastest, and what is that gap worth?
- Does site speed affect conversion rate?
- Substantially, and more reliably than it affects rankings. The effect is concentrated on mobile visitors and on paid traffic, where every lost session was bought at auction. This is why the conversion argument usually secures budget for performance work when the ranking argument does not.
- What usually makes a website slow?
- Most often unoptimised images, render-blocking third-party scripts loaded in the head, web fonts that reflow the layout after first paint, and accumulated tags in a tag manager that nobody has audited. Exotic causes exist but are rare; the common ones account for the majority of the loss on most sites.
- Is a Lighthouse score worth optimising for?
- As a diagnostic, yes; as a target, no. Lab tools run on a simulated device and connection and tell you what could be improved. Field data from real sessions, segmented by device and template, is what tells you whether visitors are actually experiencing the site as slow.