Your Site Is Slow Because of Five Files, Not Five Hundred

Slow is rarely evenly spread

A slow site feels like a general problem and is almost always a specific one. A page that takes four seconds is usually waiting on two or three files that are large, unoptimised, or fetched from somewhere far away. Fix those and the page is fast, without touching the other four hundred files.

Find the time before you fix anything

Open the browser's network panel, load the page, and sort by size and by time. You are looking for two things: the single largest file, and the file that takes longest to arrive. They are often not the same file, and the second is usually the more expensive problem.

Do this on a throttled connection, not your office fibre. On a fast connection everything looks fine, which is why sites are slow and their owners do not know.

The five usual suspects

• The hero image. A single full-width photograph at full resolution, often

several megabytes, sent to a phone. Resize it to the size it is displayed at and convert it to a modern format. This one change is frequently the whole problem.

• A web font. A font loaded from another domain blocks text from rendering

while it arrives. Serve it from your own host, limit it to the weights you use, and let the browser fall back to a system font immediately.

• A third-party script. A chat widget, a tracker, an embedded video. Each is

a request to someone else's server that you cannot make faster. Remove the ones you do not use, and load the rest without blocking the page.

• An unminified stylesheet or script. A large file with comments, whitespace

and code paths you never use. Compress it and send only what the page needs.

• A slow server response. If the first byte takes a second, no amount of

front-end work will save you, because the reader is waiting before anything else can begin. That is a hosting question, and it has its own article later in this series.

The order that pays

Fix in this order, and stop when the page is fast enough:

1. Compress and resize images. Usually the largest single win, and the safest.
2. Fix the server's response time. If it is over half a second, nothing else

matters.

1. Defer or remove third-party scripts. The largest remaining risk, and the

least under your control.

1. Self-host and subset fonts.
2. Cache what is left, so a repeat visit costs almost nothing.

What not to do

Do not start with a rebuild. Do not add a plugin that promises to optimise everything, because it will usually add a request of its own. And do not measure on your own connection, because the reader is not on it.

The test that matters is a phone, on a mobile connection, loading the page for the first time. Everything else is a comfort.