A slow site loses visitors before it has even said hello, and the cause almost always lies in the site itself rather than in the server. Here are the levers, from the most rewarding to the least.
Where slowness comes from
| What slows things down | What you can do |
|---|---|
| Images that are too heavy | Resize them before uploading |
| Too many extensions | Remove what serves no purpose |
| No cache | Enable page caching |
| A cluttered database | Tidy up regularly |
| Resources called from outside | Host them yourself |
| A very heavy theme | Choose a sober theme |
Images first
It is the most rewarding lever, by far. A photograph straight out of a camera often weighs several megabytes to be displayed in a frame of a few hundred pixels.
- Resize before uploading, to the actual display size.
- Compress: a modern format divides the weight with no visible difference.
- Defer the loading of images further down the page.
- State their dimensions in the code: the page stops jumping while it loads.
Extensions
Every extension adds code executed on every visit. Go through the list and ask a single question about each: what is it for today? If the answer is slow to come, it no longer serves.
Delete rather than deactivate: a deactivated component remains a file on the server, and an attack surface.
The cache
Without a cache, every visitor triggers the complete rebuilding of the page: querying the database, assembling, rendering. With page caching, the page is served as it is. On a content site, it is the best effort-to-reward ratio after images.
The database
Over time, the database fills with things that no longer serve: article revisions, spam comments, tables left by deleted extensions, internal logs. A periodic tidy-up shows on the pages that query a lot.
What the server cannot fix
A page that calls forty resources will remain slow on any machine. The server delivers quickly what it is asked for; it cannot decide to ask for less.
Changing plans for a badly tuned site amounts to buying a more powerful car to drive with the handbrake on. Tune first, measure, and change afterwards if it is still useful.
Measure before changing
Your browser's developer tools — the network tab — show every resource loaded, its weight, and its time. That is enough to identify the three usual culprits.
Change only one thing at a time, and measure after each change. Three simultaneous modifications can no longer be attributed.
When the plan really is the cause
If the site is tuned, light, cached, and slowness returns at peak hours, then the plan may be the limiting factor. See The limits of shared hosting and Changing plans.