Why your website is slow, and what to do about it
Slow sites are rarely slow for mysterious reasons. They are slow for a short list of ordinary ones, and most of them are fixable without a rebuild.
Contents
Site speed has become a subject people discuss in the abstract, usually with a score out of one hundred attached. That is a shame, because slowness is concrete. Something on the page is large, or late, or blocking. Find which, and the fix is usually obvious.
Here is the list we work through, in the order we work through it, because the order matters. Fixing the fifth thing first wastes a day.
First, measure the right thing
A score from a testing tool is a summary, not a diagnosis. What you want is the breakdown underneath it: how long until the main content appears, how long until the page stops moving about, and how long until it responds to a tap.
Test the pages that matter, on a phone, on a mobile connection. Your home page on office broadband is the least representative measurement available. Most people arrive on a product page or an article, from a phone, with several other apps competing for the processor.
Also separate two different problems that get conflated. A page can be slow to arrive, which is a server and network problem, or slow to become usable once it has arrived, which is a browser and code problem. They have different causes and different fixes.
Images, almost always
If a site is slow and nobody has looked at it recently, images are the cause more often than everything else combined. The usual faults:
- A photograph uploaded straight from a camera or phone, displayed at a fraction of its size but downloaded at full resolution.
- No modern format. Older formats are still served to browsers that would happily accept something far smaller.
- Everything loading at once, including images four screens below the fold that most visitors never reach.
- No dimensions declared, so the page jumps around as each image arrives and the reader loses their place.
The fix is unglamorous and highly effective: resize to the largest size actually displayed, serve modern formats with a fallback, declare width and height, and load everything below the fold lazily. Do this before anything else.
Fonts, quietly
Custom fonts are worth having and easy to get wrong. A font loaded from a third party domain requires a fresh connection before the browser can even ask for the file, and the text may be invisible while it waits. Self host the files, subset them to the characters you actually use, preload only the weights that appear in the first screenful, and make sure text is readable in a fallback face while the real one arrives.
Scripts, and how many of them there are
Every tag, pixel, chat widget, review embed, cookie banner and analytics script is code from somebody else running on your page. Each one costs a connection, a download and processor time on a device you do not control, and none of them are optimised for your site specifically.
Audit them. For each one, ask who reads the data it produces and when they last did. In our experience most sites are carrying at least one script that was added for a campaign that ended long ago. Remove what nobody uses, defer what is not needed for the first paint, and load heavy widgets only when someone interacts with the thing that needs them.
Plugin and theme bloat
On a content system, a slow site is often carrying thirty plugins where six would do. The cost is not only the code each one loads. It is that many plugins load their stylesheet and script on every page, whether the feature appears there or not.
The pattern we look for: a plugin installed to solve one small problem on one page, loading its assets site wide. Several of those and the home page is downloading the machinery for a form nobody visits.
The same applies to themes bought on a marketplace. A theme built to demonstrate every possible layout ships the code for every possible layout, and you use three of them.
The server, and what is in front of it
If the page is slow to start arriving at all, look below the site. Shared hosting on an overloaded machine, a database with unindexed queries, no caching layer, or a server in a different country to your customers will all produce a delay that no front end work can remove.
Three things usually help, in rough order of effort: put a caching layer in front of the site so repeat pages are served without rebuilding them, put a content delivery network in front of the assets so they are served from near the visitor, and move to hosting that is not oversubscribed. Measure before and after. Hosting upgrades are sold on promises and should be judged on numbers.
The things that make a page feel slow even when it is not
Perceived speed is not the same as measured speed. A page that arrives quickly but then shifts under your thumb as an advert loads feels worse than a page that took longer and stayed still. So does a button that does nothing for half a second after you press it.
Reserve space for anything that loads late. Give every interaction an immediate visible response. Avoid animation that delays content rather than accompanying it. These cost nothing and change how the site feels more than shaving a fraction off a load time.
Keeping it fast
Performance is not a task, it is a property, and properties decay. Sites get slow again because someone adds a video to the home page, or a marketing tool, or three hundred products. The defence is a habit rather than a project: check the key pages after every significant change, agree a budget for page weight and hold new additions to it, and review the third party scripts once or twice a year.
If you want somewhere to start today, open your busiest page on a phone, count the images, and look at how large the largest one is. That single check finds the problem on most of the sites we are asked to look at.