Speed is not a technical detail to be handed to a developer and forgotten. It is part of the experience, and it directly affects how much you rank and how much you sell.
It is also one of the few improvements that is simultaneously cheap, measurable, and permanent.
Search engines are measuring it
Google uses real-world loading, interactivity and visual stability as ranking signals — not lab scores, but the experience your actual visitors have on their actual devices and connections.
The practical consequence is simple: two sites with comparable content and authority will not rank equally if one of them is noticeably slower. Speed is not the biggest ranking factor, but it is one of the few you have complete control over and can fix in a week.
Visitors are measuring it too, whether they realise it or not
Nobody thinks “this page took 3.2 seconds to become interactive.” They think “this feels cheap” or “I will come back later” — and then they do not come back.
The effect compounds on mobile, on poor connections, and on first visits — which is to say, precisely the moments when you are being judged by someone who does not know you yet and has no reason to be patient.
What actually slows sites down
Images
Far and away the most common culprit. A 4MB hero photograph exported straight from a camera, served at full resolution to a phone. Compress properly, serve modern formats, size images to their display dimensions, and lazy-load anything below the fold. Most sites can halve their weight on images alone.
Too many plugins
Every plugin adds scripts, styles and database queries — on every page, whether the feature is used on that page or not. Audit them honestly. Most sites are carrying several they installed once and forgot.
Render-blocking scripts
Third-party tags, chat widgets, analytics, ad pixels, font loaders. Each one delays the moment your page becomes usable. Defer what can be deferred, remove what is not earning its place, and be sceptical of anything that must load first.
Bloated page builders
Convenience at build time, weight at run time. Builders that wrap every element in four nested containers produce pages that are heavy by construction. This is a foundational choice, and it is one of the reasons cheap sites are hard to make fast later.
No caching
If your server rebuilds the same page for every visitor, you are paying for the same work thousands of times. Caching is close to free and often the single largest available win.
The payoff, in plain numbers
Every hundred milliseconds you remove is measurable in conversion. That sounds like marketing hyperbole until you run the arithmetic on your own traffic.
Take your monthly visitors, your conversion rate, and your customer value. Model a modest lift — half a percentage point. For most businesses doing meaningful volume, the annual figure comfortably exceeds the cost of a week of performance work, and unlike advertising you pay for it once.
Where to start, in order
- Measure honestly. Use field data from real users, not a lab score on your office fibre connection.
- Fix the images. Almost always the biggest single win, and the easiest.
- Audit third-party scripts. Remove anything nobody can name an owner for.
- Enable caching. Cheap, immediate, permanent.
- Then look at the foundation. If the build itself is the bottleneck, no amount of tuning will save it.
Treat performance as a feature you maintain
Sites do not stay fast on their own. They decay — a plugin here, a tracking pixel there, an uncompressed image uploaded by someone in a hurry. Six months later you are back where you started and nobody can say exactly when it happened.
Measure it on a schedule. Set a budget you refuse to exceed. Make it somebody’s job.
A fast site feels trustworthy and effortless — and people buy from companies that feel that way. That is not a technical outcome. It is a commercial one.