The average hides everything. Where the milliseconds actually go, what the person waiting sees, and the four things that move the number — in order of return, not of difficulty.
by Nadia Maar ·
«The site is slow» almost always comes from one person, who looked at one page, on a phone, somewhere with poor signal. And they are almost always right: it is just that the slow page is not the one you are about to have optimised.
An average of 1.8 seconds across two hundred pages can contain a hundred and ninety pages at one second and ten at eight — and those ten are, given how catalogues work, the product pages: the only ones where somebody was about to buy something. The average is the statistic that exists to avoid looking at the distribution.
This piece is how you look at the distribution, what actually happens in a page's first three seconds, and which four interventions move the number. In order of return, which is not the order in which they get proposed.
Before touching anything you need three distinctions, and all three are free.
Tools that give you a score from 0 to 100 load the page once, from a data centre, over a simulated connection. They tell you why, not how much: the how much lives in the data collected by the browsers of people who actually visit, which every site with a little traffic has for free. When the two numbers disagree, the second one is right, always.
Underneath there are technical names and thresholds, but the substance is this: something appears; the thing I came for appears; I can tap it and it responds. Everything else is detail for whoever does the repairs.
| The moment | What the visitor lives through | When it starts being a problem |
|---|---|---|
| Something appears | The screen stops being white: a header, a background, something saying the site exists. | Past 1.8 seconds people start wondering whether they typed the wrong address. |
| The right thing appears | The title, the product photo, the price: the largest element in the visible area. | Past 2.5 seconds you lose a share of visits that grows quickly with every extra second. |
| It responds to a tap | I tap the filter, open the menu, add to basket: something happens immediately, even just a sign it understood. | Past 200 milliseconds the tap feels unregistered, and the person taps twice. |
| It does not move under your finger | The button is where it was half a second ago: no image arrived to push it down. | The only one of the four not measured in time, and the only one that makes people press the wrong thing. |
The last deserves an extra line because nobody reports it and everybody suffers it: content shifting while the page finishes loading. It does not cost seconds, it makes people press «remove» instead of «add». It is fixed by declaring the dimensions of every image and reserving space for whatever arrives later — it costs one attribute and shows up in no speed ranking.
Ask anyone why a page is slow and you will hear «the images». Look at a real sequence and you see something else: the problem is almost never that something takes long, it is that it starts late. Tap a row.
| document | 0 ms | 420 ms |
| main stylesheet | 440 ms | 520 ms |
| web font | 980 ms | 380 ms |
| filters script | 980 ms | 760 ms |
| product photo | 1420 ms | 1680 ms |
| tracking | 1500 ms | 620 ms |
The time the server takes to respond plus the time the response takes to arrive. Four hundred and twenty milliseconds here is not a problem: it is the part almost everyone optimises first, and almost never the part that costs. It becomes a problem past half a second, and then the cause is in the server, not the page.
BLOCKING. Until this file has arrived and been read, the browser draws nothing: that is a rule of the web, not a choice made by whoever built the site. It is also why «something appears» sits at 900 milliseconds and not at 500. You shrink it by sending the bare minimum needed to draw the first screen along with the page, and loading the rest afterwards.
The font starts AFTER the stylesheet, because it is the stylesheet that says it exists. This is the single-file queue the article is about: three files, each of them short, adding up to a second and a half because none of the three could start earlier. You break it by declaring the font in the page itself and serving it from your own domain rather than an external service.
It starts alongside the font and occupies the processor while the browser would like to draw. It does not block the first paint but it delays the response to a tap: it is why the filter feels broken for the first second. If it only serves people who tap a filter, it can be loaded when somebody taps a filter.
Here is the image everyone blames. It starts at 1.4 seconds — a second and a half in — because the browser did not know it existed: it was inside a part of the page drawn by the script. Making it lighter makes it shorter; ANNOUNCING it early, in the page the server sends, makes it start sooner. The second is worth more than the first.
Analytics, advertising pixels, chat. They barely touch the three thresholds when loaded afterwards, and they ruin all three when loaded first. It is the simplest intervention on the list: nothing is removed, it is moved after load.
The takeaway: three seconds pass between requesting the page and the photo appearing, but none of the six rows lasts three seconds. They are six short waits in a queue, and they get shorter by changing the order, not by compressing the files.
«Main content at 3.1 seconds» moves no meeting. The same thing drawn instant by instant does. The schematics below are not screenshots: they are boxes saying how much of the page has arrived.
The difference between the two rows is not a rewritten site: it is the stylesheet cut to essentials, the font served from its own domain, the photo announced in the page rather than by the script, and the tracking moved after load. Four interventions, none of which changes a single line of what the visitor reads.
Change hosting, rewrite the site in a more modern technology, or buy a distribution network. All three are legitimate and all three are expensive, and none of them touches the single-file queue from the third section — which is where the seconds are. A site served from a data centre twenty milliseconds away but with a stylesheet blocking the paint for half a second is exactly as slow as before, with one more invoice.
In the audit we take your pages sorted by traffic and by slowness, look at the sequence for the top three, and say which of the four interventions apply to you and what they are worth. It is not a fifty-page report: it is three sequences and a list of four items in order.
If the data from real visitors shows you are already inside the thresholds, I say so and we finish early — it happens more often than you would think, because the person who said «the site is slow» genuinely did have poor signal.
Technical SEO and AI search optimization
Not by looking at the site average, which hides everything: sort pages by traffic multiplied by slowness and look at the top three. The homepage is almost never there — it is the most polished page because it is the only one the bosses look at — while product pages almost always are, and those are the only pages where somebody was about to buy. And read the seventy-fifth percentile of real visitors, not a tool's average.
Because the problem is almost never that something takes long: it is that it starts late. In a typical sequence the stylesheet blocks the paint, the font cannot start before the stylesheet that declares it, and the main image starts at a second and a half because it sat inside a part of the page drawn by a script. They are short waits in a single-file queue, and they get shorter by changing the order, not by compressing files.
Three moments, not a score: something has to appear within about 1.8 seconds, the main element — title, photo, price — within 2.5 seconds, and the first tap has to get a response within roughly 200 milliseconds. There is a fourth that is not measured in time: content must not move while it finishes loading, because that costs no seconds, it makes people press the wrong button.
In order of return: move everything not needed to draw until after load (analytics, chat, pixels, maps), announce the main image early in the page the server sends, send with the document the minimum needed to draw the first screen, and reserve space for whatever arrives later. What NOT to do first is change hosting or rewrite the site: expensive interventions that do not touch the queue of waits where the seconds actually are.