The Median Page Ships 30x More JavaScript Than HTML

My working thesis was that a framework's shipped bytes exceed a page's own content by an order of magnitude. I went to the public data to check it. One half survived: the median page ships about 30 times more JavaScript than HTML. The other half did not: nothing I could read says the framework is the bulk of that JavaScript. So I am changing the thesis, and the rest of this post says what the data does and does not show.

The question

Can the interactive features readers actually use on a content page (a theme toggle, copy buttons, a table of contents that tracks your scroll) fit in under 200 lines of plain JavaScript? And how do the bytes a typical page ships compare with the bytes of the content itself?

This is the size side of my 2026-10-02 survival audit. That post argued that toolchain rot is the main way framework apps die. I stay with that argument. Here I ask whether weight tells the same story. I did not run any code for this post. Every number below is either read from a cited source or computed by hand from those sources, and you can repeat the arithmetic.

Data and where it came from

The main source is the HTTP Archive Web Almanac 2025 page weight chapter. It reports compressed transfer sizes, from a July 2025 measurement. It does not state its sample size in the text I read [1]. Medians in the chapter:

Resource	Mobile home	Desktop home	Mobile inner	Desktop inner
JavaScript	632 KB	697 KB	660 KB	719 KB
HTML	22 KB	22 KB	22 KB	22 KB
CSS	77 KB	82 KB	about 80 to 85 KB	about 80 to 85 KB
Images	911 KB	1,058 KB	354 KB	442 KB

JavaScript is about 24 to 27 percent of median page weight, and 98.1 percent of pages request at least one JavaScript file [1]. A caution: other summaries of the same report quote slightly different JavaScript medians (for example 664 and 690 KB). I use the chapter's own table and treat 632 to 719 KB as the range. The Almanac gives medians, not confidence intervals, so I have no interval for the median itself.

For framework adoption I used the 2024 JavaScript chapter. jQuery appears on 74 percent of pages, React on 10 percent, and the median mobile page has about 206 KB of unused JavaScript, which is 44 percent of the bytes delivered [2]. That last number matters below.

For framework size I used the Bundlephobia API for Preact 10.29.8, which reports 11,768 bytes minified and 4,837 bytes gzipped [3].

Method

1. Take the median JavaScript transfer size and divide it by the median HTML transfer size, for each of the four cells. Both are compressed, so the ratio compares like with like.
2. Compare a small framework runtime with the median HTML size.
3. Write a real small widget set, count its lines, and compare against the 200-line budget.

Step 1 is a ratio of two medians. That is not the median of the per-page ratios, and the two can differ. I flag it and do not hide it.

Result

Ratio. 632 / 22 = 28.7. 697 / 22 = 31.7. 660 / 22 = 30.0. 719 / 22 = 32.7. The median page ships 29 to 33 times more JavaScript than HTML. That is more than an order of magnitude, and it holds in all four cells.

The framework is not the explanation by itself. Preact's runtime is 4.8 KB gzipped [3]. That is about 0.22 of the median page's HTML, and about 1/130 of the 632 KB median mobile JavaScript. Even a runtime several times larger would be a minority of the median bundle. The bulk is something else: application code, third-party scripts, polyfills, and code that never runs. The 44 percent unused figure points the same way [2].

My original wording ("a framework's shipped bytes exceed the page's content by ten times") is therefore not supported. What is supported: total JavaScript exceeds HTML by about 30 times, and I cannot attribute that to frameworks from these sources.

A failed measurement. I also tried Bundlephobia for react-dom 19.3.0 and got 4,021 bytes minified and 1,463 gzipped [4]. I do not trust that as the runtime size. It looks like the package's entry shim, not the client renderer that a React page really ships. So I have no clean React number, and I decline to quote one. React is on 10 percent of pages [2], so the gap would be most informative for that tenth. Measuring react-dom/client is pending.

The 200-line test. Here is a theme toggle, copy buttons on code blocks, and a table of contents that highlights the section you are reading:

// theme toggle
const root = document.documentElement;
const saved = localStorage.getItem("theme");
if (saved) root.dataset.theme = saved;
document.querySelector("#theme")?.addEventListener("click", () => {
  const next = root.dataset.theme === "dark" ? "light" : "dark";
  root.dataset.theme = next;
  localStorage.setItem("theme", next);
});

// copy buttons
document.querySelectorAll("pre").forEach((pre) => {
  const b = document.createElement("button");
  b.textContent = "Copy";
  b.onclick = () => navigator.clipboard.writeText(pre.innerText);
  pre.append(b);
});

// table of contents highlight
const links = new Map([...document.querySelectorAll("#toc a")].map(a => [a.hash.slice(1), a]));
const io = new IntersectionObserver((entries) => {
  for (const e of entries) links.get(e.target.id)?.classList.toggle("on", e.isIntersecting);
});
document.querySelectorAll("h2[id]").forEach(h => io.observe(h));

That is 25 lines including two blank lines, with zero dependencies. I counted the lines by hand. I did not minify or gzip it, so I give no byte figure. By my estimate it is on the order of 1 KB uncompressed, which is a guess, not a measurement. Three features cost 25 of a 200-line budget. That supports "under 200 lines" for these features. It does not support "most interactive features", because I tested three that I picked. A search box, a comment thread or a cart would each need more, and I did not test them.

Sensitivity: which assumption moves the result most

HTML as "content". The 22 KB is markup, not the article. Images are 354 to 1,058 KB at the median [1], far larger than HTML. If you define content as everything the reader came for, including images, JavaScript at 632 to 719 KB is roughly comparable to content, not 30 times it. The "30x" is true only against HTML. This assumption moves the headline number most.

Which sites. The Almanac covers all sites, including web apps where JavaScript is the product. I found no content-site subset. If content pages ship less, the ratio falls. If they ship more third-party code, it rises. I cannot say which.

Medians. The 10th percentile of JavaScript is 0.4 KB in the chapter [1]. Many pages ship almost none. A median of 632 to 719 KB says nothing about what any one page ships. Whether framework-free content pages are a large group inside that lower tail is a question I did not answer.

Compression. Brotli covers 44 to 45 percent of JavaScript requests and gzip 41 percent [2]. Transfer sizes mix both. My Preact figure is gzip, so the comparison slightly overstates the runtime if Brotli would be used.

What this changes

I still hold that most content sites would load faster and break less without a frontend framework. The weight data alone does not prove it. It shows that JavaScript is the largest script-like cost on the page by far, and a framework runtime is a small part of it. The case against a framework on a content page rests more on what the framework invites you to add than on its own bytes. That is a weaker claim than the one I started with, and a more defensible one.

What would change my mind further: a content-only subset of the HTTP Archive showing medians near the 22 KB of HTML. Then JavaScript is not the issue for content pages, and I would drop the claim. A measured React client runtime near 40 KB gzipped would not change the 130x gap, though it would make the framework a larger piece of any small page.