Put a URL into any speed testing tool and you get a score and two dozen metrics. Most people glance at the score and close the tab, because it is not clear what to look at.
Three numbers actually determine how a site feels. Here is what each means, what counts as acceptable, and most importantly — why a high score is not the same as being fast.
1. Time to first byte
What it is: how long between the browser sending a request and receiving the first byte back.
The screen is entirely blank throughout. There is nothing to look at, only waiting.
What determines it: physical distance to the server, whether the server has to assemble the page, and whether anything is cached.
Acceptable: under 200 milliseconds is good. Above 500 people notice a pause. Above a second some of them leave.
Some real figures: Auckland to a server in Sydney costs about 110 milliseconds in network round trip alone, which is the floor set by distance. Add tens to hundreds more if the server queries a database and builds the page. Ours measures 40 to 60 milliseconds since moving to static hosting, because the content sits at the location nearest the visitor and no round trip happens.
This is the one most worth improving, because it is pure waiting with no visual progress, and improving it is usually architectural rather than a matter of detail.
2. Largest contentful paint
What it is: how long until the largest element on screen — usually the hero image or headline — has rendered.
This is the number closest to what a person means by “it loaded”. Before it, they are looking at blank space or something half-built.
What determines it: time to first byte, plus downloading the above-the-fold assets, plus rendering. It contains the first number, so improving that improves this one too.
Acceptable: Google suggests under 2.5 seconds. Over 4 is poor.
The usual culprit is the hero image. If your page opens with a large background photograph, its file size decides this number directly. An uncompressed photo might be 5MB, which is several seconds on mobile data — one of the main causes discussed in our piece on mobile performance.
3. Cumulative layout shift
What it is: how much the content jumps around while the page loads.
The familiar scenario: you go to tap a button, an image above it finishes loading and pushes the button down, and you tap something else. Or you are reading and an advert appears and displaces the text.
It does not affect speed and heavily affects perception. A technically fast page that keeps moving is described by users as a bad website.
Acceptable: below 0.1. It is a unitless score where smaller is better.
Three common causes: images without declared dimensions, so the browser cannot reserve space until they arrive; font swapping, where text renders in a system font and reflows when the web font loads; and content inserted late — adverts, notification bars, chat widgets.
All three are straightforward to fix permanently: declare image dimensions, choose the font loading strategy deliberately, reserve space for anything inserted later.
Why a high score is not speed
The part most worth understanding.
A tool’s score is a weighted composite of many metrics, some only loosely related to how a page feels. Optimising for the score sometimes does nothing for real experience and occasionally harms it.
Common examples: splitting stylesheets finely to reduce an “unused CSS” penalty, which increases the number of requests; compressing images aggressively for points, producing visible degradation — when image quality is the core of the offer for a renovation company or a photographer.
More fundamentally: a testing tool measures its own environment, not your customers’. Its network conditions are simulated and its location may be in another country. A site scoring 95 can still feel slow on a phone in Auckland.
So use them properly: read the three specific numbers, not the total. The total is useful for comparing one site before and after a change, and not for comparing two different sites.
Measuring it yourself
Three approaches, coarse to fine:
Browser developer tools. The most convenient. Open the network panel, tick disable cache, select a slow network preset, refresh. You see the load time of every asset and the total. This is closest to reality, because it originates from where you actually are.
The command line. For time to first byte alone, one curl command showing time_starttransfer suffices. Its advantage is running it repeatedly to see variance — a single measurement means little, since a cache hit and a miss can differ tenfold.
Online tools. Good for a full report and a list of suggestions. Remember the caveat: treat the score loosely and read the three numbers and the specific issues listed.
A practical suggestion
Measure before deciding to optimise.
Plenty of sites are fast enough, and the time would return more spent on content. The test is simple: on a phone, cache disabled, throttled to slow 4G, open your home page and count until content appears.
Under three seconds, speed is not your bottleneck — go and do something else. Over five, it is worth addressing, and the cause is usually concentrated in one or two places, most often images or fonts, without needing a rebuild.
These three are a baseline check on every project we deliver at no extra charge. For a site already live, the method above needs no tools and no help.