The median AI tool homepage ships 177 KB of HTML before anything else loads

There is a number most teams never look at, because nothing in their workflow shows it to them: how large the HTML document is. Not the page — the document. One request, before a single script, font or image is fetched.

We measured it for every listing in this catalogue on 10 August 2026. 672 of 701 answered.

The distribution

Median script tags: 25. At the 90th percentile: 77.

Median time to the first byte of the response: 369 ms; at the 90th percentile, 904 ms. The slowest we saw took 3.7 seconds before the first byte arrived.

The heaviest documents

Zed's 665 script tags are not a typo, and neither is Potpie's 2.7 MB from nine.

Those two rows are the same problem arriving by different routes. Potpie's weight is data — state serialised into the document for the client to pick up. Zed's is structure — hundreds of small inline blocks. Both end up as markup the browser has to parse before it can do anything with the page.

Why nobody notices

Because compression hides it. Potpie's 2,743 KB document arrives as 308 KB on the wire — a ratio close to nine to one, and entirely normal for HTML, which is the most compressible thing on the web.

So on a good connection the page feels fine, and every dashboard that reports transfer size says it is fine. What compression does not do is make the document smaller once it arrives. The browser still decompresses, parses and builds a tree from 2.7 MB. That work happens on the device, and it is worst on the cheap phone you are not testing on.

Only 72 of the sites we measured send a content-length header at all — the rest stream the response — so we cannot report a median compression ratio across the catalogue honestly. Among those 72 the median is about 5.6 to 1, and the individual cases above were re-fetched by hand to confirm both numbers.

What is actually worth doing

Look at the number once. curl -s https://yoursite.com | wc -c gives you the decoded size in one line. If it comes back over half a megabyte, you are in the top sixth of this dataset.

If it is large, find out which kind of large it is. A document heavy with serialised state is a data problem — usually a framework shipping the whole payload for a page that needed a fraction of it. A document heavy with tags is a build problem. The fixes have nothing in common, so the diagnosis has to come first.

Check you are compressing at all. Thirteen sites here serve their HTML uncompressed, including one at 312 KB. That is a setting, not a rewrite.

Do not chase the median. 101 listings ship under 50 KB and they are not worse products. Small is achievable; it is just not automatic.

What we are not claiming

This is the document and nothing else. A 40 KB page pulling in 4 MB of JavaScript is worse for a visitor than a 400 KB page that pulls in nothing, and this measurement cannot see the difference. It is a floor, not a score.

One request per site, from one machine, on one day, over one connection. The time-to-headers figures are the least reliable thing here: they include DNS, TLS and the distance between our machine and their server, so treat them as a rough distribution and not as a measurement of anyone's infrastructure. 29 sites did not answer us and are excluded rather than counted as slow.

Where a site sends no content-length, its wire size is recorded as unknown rather than assumed. Script tags are counted by matching <script in the markup, which counts an inline block and a remote import the same way — deliberately, since both are parsed, but it means the number is not "how many files this page downloads".