Website speed comes down to a handful of decisions — how the largest image is delivered, how the fonts load, how much forgotten code still runs, and whether the layout holds still while the page arrives — and the order you fix them in matters more than how many you fix. 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 it rarely changes. Order matters because the items near the top account for most of the delay a person can feel, while work further down is easy to mistake for progress: you can compress every file on a page and still ship a hero image that takes four seconds to appear on a phone.
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.
Telling the browser early is the fix people skip, and the mechanism explains it. A browser cannot request an image it has not discovered, and it discovers most images only after parsing the HTML and the stylesheet that positions them; a preload hint moves that discovery to the first moment of the page’s life. Urgency is shared, though, so one image gets it and the rest wait. The common failure is the opposite: a lazy-loading rule applied to every image on the site, which deliberately delays the largest one in the first screenful.
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.
Font loading goes wrong in two directions. Block the text until the font arrives and someone on a slow connection reads nothing for seconds on a page that has otherwise finished loading. Swap it in against a fallback of a different width and the paragraph re-flows under their eyes as they start reading — that is the flash people remember. The way out is a fallback whose metrics are close to the real font, adjusted until the two occupy nearly the same room.
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.
A forgotten script also costs more than its file size suggests. It occupies a connection, and then it runs — and while it runs the browser cannot draw anything else, so a tag that weighs almost nothing can hold a page still for a moment. Some of it is load-bearing, though: the payment script, the consent banner, the analytics someone genuinely reads. Deleting tags by guesswork is how a checkout quietly stops recording orders, so find an owner for every line and remove what nobody claims.
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.
The browser lays a page out with what it knows, and lays it out again whenever it learns something new. An image with no dimensions in the markup is an unknown height, so everything beneath it is positioned twice — once wrongly, then once correctly.
The layout shifts that survive every audit are the elements that arrive late by design: a cookie banner that pushes the page down, a font swap that turns a two-line heading into three, an embed handed a container with no floor. Each one is invisible to whoever built the page, whose browser has the font cached and dismissed the banner months ago, and shows up for the visitor arriving for the first time on a phone.
Website speed does not end when the page finishes loading
A page can arrive quickly and still feel slow, because loading and responding are two different problems. The browser draws the page and runs your code on the same single thread, so while a script is busy the tap someone just made waits its turn. The button does not react for a beat, and they press it again.
A load score cannot see this, because the score is measured on a page nobody touched. Look instead for work that happens on a schedule rather than on demand: a script running on every scroll event, a filter that rebuilds several hundred rows whenever one value changes. Interactive features cost main-thread time, and some are worth it — but the cost belongs where a visitor asked for something, not on the way in.
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.
Measure the same page twice, before and after, on the same throttled profile; a run on a warm cache measures your own browser’s memory rather than the site. A test you run yourself describes conditions you chose; field data from real visits describes what happened to visitors who chose nothing, and it is the version to trust when the two disagree.
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.