Skip to content
modernwebsite.

Performance

What Actually Makes a Website Fast

Speed scores are a symptom, not a cause. Here is what genuinely moves them, in the order that matters.

Published
18 June 2026
read
6 min

Most conversations about site speed start with a score out of 100 and stop there. The score is useful as a smoke alarm, but it tells you the kitchen is on fire without telling you which pan. What follows is the order we work in, and why that order rarely changes.

The largest image on the screen

On most pages, the single slowest thing is the biggest image in the first screenful. It is usually uploaded at whatever size the camera produced, served at that size to a phone, and often loaded after the rest of the page has already worked out where to put it.

Three fixes, in order of impact: serve it in a modern format, serve it at the size the device will actually display, and tell the browser about it early so it can start fetching before it finishes reading the stylesheet. That combination routinely takes seconds off a page — more than any amount of code minification.

Fonts, and the flash they cause

Custom fonts are worth their weight, but only if they are self-hosted and preloaded. A font requested from a third-party domain adds a DNS lookup, a connection and a download before a single word can be drawn in the right typeface.

Self-hosting removes the first two. Declaring a sensible fallback and a swap behaviour removes the blank pause. The visitor sees text immediately, and it settles into the right face a moment later.

Everything you added and forgot

The third-party script for the chat widget you trialled two years ago is still loading. So is the analytics tag from the agency before us, the heat-mapping tool nobody looks at, and two fonts used by a page that no longer exists.

Auditing what a page loads is unglamorous and almost always the second-largest win. Every script you remove is a request that never happens, on every visit, forever.

Layout that stops moving

A page can be fast and still feel broken if things jump while it loads. Reserve space for images and embeds before they arrive, and give any element that appears later a size the browser can plan around. The measurable version of this is cumulative layout shift; the human version is not tapping the wrong button because the page moved.

Then measure, on the connection your visitors have

A site tested on office fibre is not a site tested. Throttle to a mid-range phone on a slow connection and look again. That is the experience most visitors are actually having, and it is where the remaining work reveals itself.

We do not promise a specific score, because hosting, content and third-party tools all move it after launch. What we promise is that these decisions are made deliberately, and measured before and after.

Have a project like this?