I measure other people's pages and write to the owners about what I find, so I care a lot about which of my numbers are safe to quote. My working rule for a long time was:
Load time is a range — it depends on the network. Page weight is stable. Build the argument on weight.
That rule is mostly right, and last week it was wrong in a way I want to write down, because the failure is more interesting than the rule.
Same page, two visits, ten minutes apart
| visit 1 | visit 2 | |
|---|---|---|
| total transferred | 14,486 KB | 55,245 KB |
| requests | 533 | 638 |
| first-party only | 6,499 KB | 4,388 KB |
| time to ready | 25.3 s | 11.5 s |
Nearly four times the weight — and it got faster.
Both numbers are real. Nothing was cached differently on purpose, nothing changed on their server. If I had measured once and written a message, I'd have quoted either 14 MB or 55 MB with equal confidence, and been equally wrong either way.
What was actually happening
An Instagram feed widget in the footer. On the second visit it pulled eight or more videos, 2.3–4.0 MB each, from cdninstagram.com.
How many it manages to fetch depends on how quickly the run reaches the footer and how long it lingers — which is a property of my measurement, not of their page. And the inversion makes sense once you see it: on the faster visit the page became ready sooner, so the footer widget got more time to keep pulling videos before I stopped counting. Speed caused the weight.
Note the third row, too. Their own first-party bytes moved from 6,499 KB to 4,388 KB — a third of a swing, from a source I haven't fully explained. Even the "stable" half of the measurement is only stable-ish.
So the amended rule:
Measure weight twice. If the second run differs by more than about 1.5×, stop measuring the page and go find the third-party widget. Then write about the widget, not about "page weight."
And: never fold third-party video into "the weight of their site." Those bytes are real and worth telling someone about, but they belong to an embed, and putting them in a single total lets one wrong assumption discredit every other number in the message.
The other blind spot: the heaviest file is often not yours
A related case, from a different kind of site — a product that audits pages for SEO and speed. I ran its own home page through the same lens.
The heaviest single file was Google Tag Manager: 169,522 bytes over the wire, 498,110 decompressed. For comparison, on the same page:
- their own JS bundle: 116,026 bytes over the wire
- their CSS: 81,318 over the wire
The analytics tag is bigger than the application. On a page-speed product.
I don't think anyone was careless. GTM is pasted in once, near the beginning, by whoever set up analytics, and it never appears in a bundle report again — it isn't in your package.json, your bundler never sees it, and your build output never mentions it. It is invisible to exactly the tools you'd use to look for it, including, in that case, the site's own product.
Both stories are the same story: the things that distort a page most are the things outside the boundary your tooling draws. A bundler measures your bundle. A framework's image pipeline measures the images you handed it. An embed measures nothing at all and answers to no one.
What I actually do now
- Two cold runs, always. One run is an anecdote.
- Split first-party from third-party in the report, never a single grand total. The split is usually the finding.
- If the two runs disagree by more than 1.5×, don't quote a weight at all — name the widget and quote its files.
- Sort by transfer size and read the domains, not just the file names. If the top entry isn't served from the site's own domain, that's the headline.
- Quote decompressed size next to over-the-wire size for scripts. 169 KB sounds survivable; 498 KB of JavaScript to parse on the main thread is a different sentence about the same file.
None of this is sophisticated. It is just the difference between a number you can defend and a number that collapses the first time the recipient reloads their own page and sees something else.
Why bother
Because an unsolicited measurement is worth exactly as much as its credibility. Send someone "your site is 55 MB", have them check and see 14, and you have not made a small error — you have converted yourself into spam, and every accurate thing you also said goes in the bin with it.
The two-run rule costs one extra page load. It is the cheapest insurance I know of.
I build browser tools where this kind of measurement is the job — parametric product configurators and engineering calculators, where the geometry and the costing come from the same parameters so they can't quietly disagree. Work at smirnov-artur.github.io/webgl, and I'm on Telegram at @smirnovarturr or at paladei702@gmail.com.
If you have a page where two cold runs disagree by more than 1.5×, I'd genuinely like to see it. My guess is there's a video embed in your footer.
Top comments (0)