A site that takes its time is rarely broken in one obvious way. It is usually four smaller things stacked on top of each other, and the order you fix them in matters more than the fixes themselves. Here is how to work out what is actually slow, in the order that stops you wasting a weekend on the wrong thing.
First: is it the site, or is it you?
Before blaming the website, rule out the two things that fake the symptom. Open the same page on mobile data with wifi switched off, and ask somebody in another town to open it too. If it is quick for them and slow for you, the site is fine and your connection or your browser is not.
This is the “fast internet but slow website loading” case, and it catches people out because the internet speed test says everything is fine. A speed test measures how much data your line can move. It says nothing about how long a particular server takes to start answering, which is a different question entirely.
The other faker is your own browser cache. You have visited the site a hundred times, so it feels instant to you and slow to everyone else. Load it in a private window before you form an opinion.
What “slow” actually means
There are two numbers worth knowing, and neither of them is a score out of a hundred.
The first is how long the server takes to start answering. You ask for a page, and nothing at all can happen until the server sends back its first response. On a site with nothing in front of it, that is where most of the wait lives.
The second is how much has to travel and how big it is. A page that answers instantly and then downloads five megabytes of uncompressed photographs is still a slow page, just slow in a different place.
Testing tools do not measure either of these. They score how a page is built against a checklist, which is useful for finding problems and useless as a target. I have made a site four times quicker to answer and I could not tell you what it did to its score, because that is not what I was measuring.
The four places slowness hides
Almost every slow site is slow in one or more of these, and they are listed deliberately from the inside out.
The server
How much work the site does before it can say anything at all: the PHP version it runs on, whether repeated database queries are being remembered or recalculated from scratch every time, how much the plugins do on every single request. This is the deepest layer and the least visible.
The page itself
The usual culprits, in rough order of how often they turn up: an image that is three thousand pixels wide being displayed at four hundred, a hero image told to load lazily so it arrives after everything else, video that autoplays because it looked good in the demo, and fonts loading in a way that leaves text invisible while you wait.
Delivery
How the stylesheets and scripts reach the browser, and which of them genuinely need to arrive before anything can be drawn. Most of them do not.
The cache
Whether the server rebuilds the whole page for every visitor, or hands over a copy it made earlier.
Why the cache goes last, even though it is the quickest win
Caching is the step everyone starts with, because it is the one that shows a better number by tomorrow. It is also the reason so many sites are stuck: a page cache hides everything underneath it.
Turn it on first and every change you make afterwards measures the same, because you are timing how fast the server can hand over a file it already made. Your images are still too big. Your server is still slow. You just cannot see it any more, and neither can the next person who tries to help.
Worse, a setting that quietly breaks a page can sit hidden behind cached HTML for days before somebody notices.
The one that surprises people: no cache at all
It is more common than it sounds, and it is worth checking before anything else, because it is the difference between a slow site and a site doing entirely unnecessary work.
A shop I look after was rebuilding its entire home page from scratch on every single visit, for every single visitor. Nothing was misconfigured. There was simply no page cache installed at all, on a server perfectly capable of running one. Measured before and after, on the same machine on the same day, the home page went from 2.10 seconds to 0.49 seconds.
That is not a clever optimisation. That is a site that had been paying for the same work over and over, and stopped.
If you run WordPress, do these in this order
Assuming you have ruled out your own connection:
- Look at your biggest images first. Not all of them. The one in the header, and any that appear before you scroll. If a photograph is more than a few hundred kilobytes, it is doing damage.
- Check the hero image is not lazy-loaded. Lazy loading is genuinely useful for images further down. Applied to the first thing on the page, it delays exactly the thing you wanted to arrive first.
- Find out whether a page cache exists at all, and whether it is actually serving.
- Only then start switching on the clever options, one at a time, opening the site after each one.
What not to do
Three mistakes cost more time than the problem did.
Do not install a second caching plugin. Two plugins doing the same job is not twice as fast; it is a fight, and the loser is your site. Pick one and remove the rest.
Do not switch on everything the plugin offers. The aggressive options — combining all your stylesheets and scripts into one, stripping out what an algorithm thinks is unused, delaying every script until interaction — are the ones that break checkouts, menus and forms. They can be worth it, one at a time, with the broken bits excluded afterwards. Switched on together on a Friday, they are a bad weekend.
If you sell online, do not cache the shop like a brochure. Basket, checkout and account pages must never be cached and stored for the next visitor. Get this wrong and one customer is shown another customer’s basket. It throws no error and appears in no log; the site simply looks fine while it leaks. The plugin’s own defaults for shops are a starting point, not a proof: it needs testing with a real basket.
When it really is the hosting
Sometimes it is, but less often than hosting companies would like. Most of what makes a site slow lives inside the site rather than underneath it, and moving a slow site to a faster server usually buys you a slightly quicker slow site.
The way to know is to measure the server answering a page it has never seen before, so nothing can be served from a cache. If that is consistently slow after the inside of the site has been dealt with, then the ceiling is real and worth paying to raise. Before that, it is a guess with a price tag.
The short version
Rule out your own connection. Understand that a score and a speed are different things. Work from the inside out: server, then the page, then delivery, then the cache. Change one thing at a time and open the site after each one. And if you sell online, test the basket before you leave any of it switched on.
If you would rather not do any of that yourself, this is how I do the speed work, measured against your live site rather than against a testing tool. It is included in every care plan rather than sold as an extra, and the first look at your site does not cost anything.
