Website speed gets filed under technical maintenance — something for whoever built the site, addressed when someone complains.
It behaves like a commercial variable. Speed affects whether pages get crawled and indexed, contributes to how they rank, and materially changes how many visitors stay long enough to do anything. It sits at the intersection of the discoverability and conversion layers, which is why improving it tends to pay twice.
The three ways speed costs you
Crawling and indexing
Search engines allocate finite resources to any given site. A slow site is crawled less thoroughly, which means new pages take longer to be discovered and changes take longer to register.
For a small site this rarely matters. For a site with hundreds of pages — a catalogue, a large content library — it becomes a genuine constraint on how much of your site is actually in the index.
Ranking
Page experience is one input among many, and it is a comparatively weak one. Speed will not rescue a page that answers a query badly.
It functions more as a differentiator between pages that are otherwise comparable. If your answer and a competitor's answer are similarly good, and theirs loads in a second while yours takes six, that is a reasonable thing for a search engine to factor in.
Treating speed as the primary lever is a mistake. Treating it as irrelevant is also a mistake.
Abandonment
This is the largest and most direct cost, and it is not really about search at all.
People leave slow pages before they see them. The visitor never evaluates your offer, your evidence or your call to action, because none of it rendered. Every acquisition channel is affected simultaneously — paid traffic especially, since you paid for each of those departures.
This is why speed is a conversion issue as much as a ranking one, and why it belongs alongside the failures in why most company websites don't convert.
Measure the conditions your visitors actually have
The most common error is testing on a fast laptop on office broadband and concluding the site is fine.
A large share of real traffic is on mid-range phones on mobile data, sometimes on congested networks. That is the condition that matters, and it can be several times slower than the developer's experience.
Two kinds of measurement, both worth having:
Lab testing — a tool loading your page under simulated conditions. Repeatable, useful for diagnosis, but synthetic.
Field data — what actual visitors experienced. Less controllable, more honest. This is the one that reflects reality.
When they disagree, believe the field data. It is describing your customers.
What usually causes it
In rough order of frequency, for typical business sites:
Unoptimised images. By far the most common. Photographs uploaded at camera resolution, served at full size to a phone displaying them small. Frequently the single largest fix available, and among the easiest.
Too many third-party scripts. Analytics, chat widgets, tracking pixels, embedded fonts, social embeds. Each is small; collectively they often exceed the site itself. Every one is also a dependency on someone else's server being fast.
Fonts loading badly. Web fonts that block rendering, or cause text to reflow after loading. Visible as a page that flickers or shifts while settling.
Heavy page builders. Convenience tooling that ships large amounts of unused code to every visitor.
No caching or CDN. Every visitor fetching everything from origin, from wherever that origin is.
Layout shifting. Content moving as things load. Not strictly speed, but it is measured as part of page experience and it is genuinely annoying — people tap the wrong thing.
The order to fix things
Images first. Almost always the biggest gain for the least work. Correct dimensions, modern formats, and lazy loading for anything below the fold.
Audit third-party scripts second. List every one and ask what it does. Most sites carry at least one script nobody can account for — a tag from a former agency, an abandoned tool.
Then caching and delivery. Frequently a configuration change rather than a rebuild.
Then fonts. Limit weights, load them without blocking rendering.
Rebuild last, if ever. A slow site is usually a configuration problem, not an architecture problem, and rebuilding is the expensive answer to a question that rarely required it.
Where this connects to the rest
Speed sits underneath both discoverability and conversion, which is why it is easy to under-prioritise — it belongs to nobody in particular.
The practical consequence: it should be checked on a schedule rather than when someone complains. Sites get slower gradually. A tracking script added here, an uncompressed image there, a plugin for one campaign that never got removed. Nobody decides to make a site slow; it accumulates.
An occasional audit — what is loading, why, and does it still need to — prevents most of it.
What we do
Performance is treated as a build requirement rather than an optimisation phase in our work, which comes from the engineering side of the business: a system that is slow under load has failed, regardless of whether it is technically working.
Concretely, that means images sized and served appropriately, third-party scripts justified individually, and measurement against realistic conditions rather than a developer's machine. The same instinct that produces focused screens rather than dashboards applies here — the discipline is subtraction, and most speed problems are things that were added without anyone asking whether they earned their cost.
Frequently asked questions
How fast does a site need to be?
Fast enough that a visitor on a mid-range phone on mobile data sees meaningful content quickly. Chasing a perfect score in a testing tool has diminishing returns; the difference between a slow site and a reasonable one is where the value is.
Do we need to worry about this if traffic is low?
Yes, and arguably more — with low traffic every visitor matters more, and abandonment is a larger proportional loss.
Will fixing speed improve our rankings?
Possibly slightly, and it is not the main reason to do it. The reliable return is fewer people leaving before the page renders, which improves every channel at once.
Should we remove our chat widget and analytics?
Not necessarily. Audit them: what each does, whether it is used, and what it costs in load. Keep what earns its place. The common finding is one or two scripts nobody can explain.
Is a rebuild the answer?
Rarely. Most slow business sites are slow because of images, scripts and configuration — all fixable without rebuilding. Rebuild when the architecture is genuinely the constraint, which is less often than it is proposed.
Where to start
Open your own site on a phone, on mobile data, not on your office network. Time how long until you can read something useful.
Then list every third-party script on your site and account for each. Between images and scripts you will usually find most of the problem, and neither requires rebuilding anything.
SEO for businesses that have never done it covers where this sits in the discoverability layer. If you want an assessment of what is actually slowing your site, talk to us.