Every few weeks someone sends us a screenshot of a performance score and asks why their site is slow. The score is usually red. The site is usually fine. Somewhere else on the same site there is a real problem that the score never mentioned.
Why scores mislead
A single number has to compress a lot of detail, and compression loses things. A page can score badly because of one third party script that loads after everything a visitor cares about. It can score well while the largest image on screen takes four seconds to appear on a phone.
The number is a starting point for a question. It is not the answer. What matters is when the page becomes useful, which is a different measurement entirely.
A score tells you something is wrong. It rarely tells you what, and it almost never tells you what to fix first.
Weight is not the problem
Total page weight is the metric people reach for because it is easy to understand. It is also the one that correlates worst with how fast a page feels.
A recent example from our own audit work. A homepage carried 1.3 MB of images across ten files, which sounds alarming until you look at where they sit:
| Asset type | Files | Weight |
|---|---|---|
| Images | 10 | 1,323 KB |
| JavaScript | 19 | 106 KB |
| CSS | 33 | 77 KB |
Every one of those images sat below the fold and was lazy loaded. None of them delayed the first paint by a millisecond. The 33 CSS files, small as they were, all had to be fetched and parsed before anything rendered at all.
Worth knowing. Resizing those images would have made the site slower. The source screenshots were tall and narrow, and the generated smaller versions were upscaled to a wider standard size. Four of them came out heavier than the originals.
What actually blocks a render
Three things decide when a page becomes useful, and none of them is total weight.
- Render blocking requests. Stylesheets and synchronous scripts in the head stop the browser painting until they resolve.
- The largest element above the fold. Usually a hero image or a heading. If it is lazy loaded, you have told the browser to deprioritise the one thing the visitor is waiting for.
- Layout shift. Content that arrives without reserved space pushes everything else around. The page may be fast and still feel broken.
The lazy loading trap
Lazy loading is good for images a visitor may never scroll to. Applied to the hero, it does the opposite of what you want. A single attribute is the difference:
<!-- delays the thing people are waiting for -->
<img decoding="async" src="hero.webp" loading="lazy">
<!-- loads it first, reserves its space -->
<img fetchpriority="high" fetchpriority="high" decoding="async" src="hero.webp" width="1200" height="675" fetchpriority="high">
The width and height attributes matter as much as the priority. They let the browser reserve the space before the file arrives, which is what stops the layout jumping.
How we measure it
Before changing anything we take three readings, because a fix that improves one and damages another is not a fix.
- A load waterfall, to see what is fetched, in what order, and what waits on what.
- Field data where it exists, because a fast connection hides most problems.
- The actual byte size of every asset, measured rather than assumed.
That last one catches more than you would expect. It is how we found the upscaled images in the example above, and it takes a few minutes.
Fixing things in the right order
Order matters, because the cheap changes often remove the need for the expensive ones.
- Fix the above the fold image. Priority, dimensions, correct format.
- Cut render blocking requests. Minify first, and be careful with combining.
- Preconnect to any font or asset host you cannot remove.
- Only then look at total weight, and only where a smaller file is genuinely smaller.
Most sites we look at need the first two and nothing else. If you want a second opinion on where your own time is going, tell us what you are seeing.
