When a site is slow, the assumption is that it needs a developer. By the time it reaches development, most of its speed has already been decided — in choices about content, layout, and what gets loaded.
When a site is slow, the assumption is usually that it needs a developer to optimise it. That’s sometimes true. But by the time a site reaches development, most of its speed has already been decided — in choices about content, layout, and what gets loaded.
Which is good news, because design decisions are cheaper to change than engineering ones.
Where the weight actually comes from
In rough order of how much they cost you, the things that make a site slow are:
- Large numbers of high-resolution images, served at full size regardless of the screen displaying them.
- Videos and animation that load immediately and run on the homepage, competing with the content for bandwidth.
- Fonts — several families, many weights, all loaded before anything renders.
- Third-party scripts: chat widgets, tracking, embedded maps and forms. Each one is a connection to another server, and they add up.
- Layouts that shift as elements load, which feels slow even when the total time is fine.
Almost none of these are engineering problems. They’re decisions about what to include and how much of it.
The decisions that matter most
Three choices, made early, determine more of the final performance than any later optimisation:
How much is on the first screen
Every element at the top of the page competes to load first. A hero with a background video, an animated graphic, three fonts, and a carousel will be slow regardless of how well it’s built. A hero that’s mostly type will be fast almost by default.
How images are chosen and served
One large image, correctly sized and served in a modern format, costs a fraction of five medium ones at full resolution. This is largely decided at the point someone picks the photography, not at the point it’s coded.
How many outside services get embedded
Each third-party script is another company’s server deciding how fast your page loads. Fewer is almost always faster, and the ones you keep should justify themselves.
A useful habit
Load your site on a phone, on mobile data, in a place with ordinary reception. Not on office wifi, not on a desktop. That’s how a meaningful share of your visitors experience it, and it surfaces problems that are invisible on a fast connection.
Why this is good news
If speed were purely a technical problem, fixing it would mean an expensive development project every time. Because it’s largely about what’s on the page, it’s fixable by deciding to include less — which costs nothing and often improves the design.
A fast site is usually a focused site. Speed and clarity tend to be the same decision made from two directions.
What to check first
Start with the largest image on your homepage and the number of third-party scripts. Those two account for most of the problem on most sites, and both are changeable without touching the underlying build.
Then look at the top of the page and ask what could be removed rather than optimised. The answer is usually at least one thing, and removing it is more reliable than making it faster.