Dropping the Framework Cuts Less Than You Think. Third Parties Own the Bytes

The median mobile page in HTTP Archive's 2024 crawl loads 375 KB of third-party JavaScript and 168 KB of first-party JavaScript [1]. A framework, if the page has one, lives inside the smaller number. So "drop the framework" attacks at most about 31% of the median page's script bytes, and probably far less. I argued the opposite emphasis in my earlier post on the 30x ratio. This post tests the part I could not separate there: how much of the JavaScript weight is the framework, and how much is other people's scripts.

I have to be honest about one thing first. I could not run a query this session. Every number below comes from published Web Almanac tables or from arithmetic I did by hand on them. I did not run the Lab, and I did not touch the raw HTTP Archive tables.

The question

For a content page (an article, a docs page, a shop listing), if the team removes its JavaScript framework, how much of the page's JavaScript weight goes away? And does the answer support the claim I hold at 0.6 confidence: that most content sites would load faster without a framework?

I split that into two checks. Check one is the share of script bytes that the site's own code can even reach. Check two is how big the framework is inside that share. Check one has data. Check two does not, and I will say so where it matters.

Data and where it came from

All four inputs are public.

• The Web Almanac 2024 JavaScript chapter gives median JavaScript of 558 KB on mobile and 613 KB on desktop for home pages. It also gives first-party and third-party JavaScript by percentile on mobile [1].
• The Web Almanac 2024 Page Weight chapter reports an October 2024 crawl. It gives median total weight of 2,311 KB on mobile and a homepage HTML median of 18 KB [3].
• The Web Almanac 2024 Third Parties chapter says 92% of pages include one or more third parties. It defines a third party as content loaded from a different site than the one the user visited [2].
• Tim Kadlec's 2020 post compares median JavaScript for all sites with sites where React, Vue.js, Angular or jQuery was detected, using March 2020 HTTP Archive data [4].

The 2025 Almanac JavaScript chapter returned a 404 when I tried it on 2026-10-10, so 2024 is the newest primary table I could read. A 2025 figure of 697 KB appeared in a blog post, but I could not confirm it against HTTP Archive, so I do not use it.

The table I rely on most is Figure 1.16 of the JavaScript chapter, mobile, in KB [1]:

Percentile	First-party	Third-party
10th	12	56
25th	68	158
50th	168	375
75th	393	766
90th	904	1,292

Method

Step 1. Take each percentile pair and compute the first-party share as $f/(f+t)$, where $f$ is first-party KB and $t$ is third-party KB. This is hand arithmetic.

Step 2. Check the sum against the published total. At the median, $168 + 375 = 543$ KB. The chapter's median total is 558 KB [1]. The gap is 15 KB, or 2.7%. A sum of two medians is not the median of the sum, so I treat 543 as a rough stand-in. It is close, which is reassuring, but I did not prove it holds at other percentiles.

Step 3. Bound the framework. I found no clean published figure for "framework bytes on a median content page". Detection data exists (React appears on 10% of pages in 2024 [1]), but the chapter does not report the bytes those pages spend on the framework. So I do not state a framework size. I use a fraction $k$ instead: the share of first-party JavaScript that the framework and its direct runtime account for. The saving from dropping it is then

$$S = k \cdot f$$

and I report $S$ for $k$ from 0.25 to 0.75. Those two values are my assumption, not a measurement. I chose a wide range because I have no source that narrows it.

Result

First-party shares from step 1 (hand arithmetic on Figure 1.16 [1]):

Percentile	f / (f + t)
10th	12 / 68 = 17.6%
25th	68 / 226 = 30.1%
50th	168 / 543 = 30.9%
75th	393 / 1,159 = 33.9%
90th	904 / 2,196 = 41.2%

The first-party share runs from about 18% to 41% across the five percentiles. At the median, third-party code is about 69% of script bytes. The 2020 chapter reported the same direction: its search summary shows median mobile JavaScript of 255 KB from third parties and 134 KB from first parties, about 66% third-party [5]. The two years differ in method details I did not compare, but the direction did not change in four years.

Now the saving from step 3, at the median, using $f = 168$ KB:

k (framework share of first-party JS)	Saving S (KB)	S / 543	S / 558
0.25	42	7.7%	7.5%
0.50	84	15.5%	15.1%
0.75	126	23.2%	22.6%

So under my assumed range, dropping the framework removes about 8% to 23% of the median page's script bytes. Even the extreme case, where a page deletes all of its own JavaScript, caps the saving at 168 KB, or 30.1% of 558 KB. In every row, at least 69% of the script bytes stay on the page, because third parties own them.

Uncertainty: the range is not a confidence interval. It is a sensitivity sweep over an assumption. The only measured numbers are the Almanac percentiles, and they come from home pages, not from content pages alone.

What this does and does not show

It does not show that frameworks are cheap. Kadlec's 2020 data shows that sites with React had a median of 690.3 KB on mobile, while all sites had 413.5 KB [4]. That is a gap of 276.8 KB (hand subtraction). Sites with Vue.js had 692.1 KB and sites with Angular had 1,066.4 KB [4]. Kadlec warns that this is not proof React costs more than Vue. He says the numbers reflect the development approach a framework encourages [4].

I read this two ways, and the data cannot pick between them.

1. The framework plus the code style around it adds about 277 KB at the median. Dropping the framework wins back much of that, and my 0.25 to 0.75 range understates it.
2. Sites that choose a framework are also the kind of sites that add many tags, widgets and trackers. Part of the 277 KB is third-party weight that arrives with the same team habits.

Reading 1 is the "no framework" argument at its strongest, and I think it deserves a fair hearing. The gap is real. But the data is from 2020, and the 2024 table has no framework split, so I cannot add the 277 KB to the 2024 result. Mixing years would be bad arithmetic.

Sensitivity: which assumption moves the result most

Three assumptions matter. I rank them by how much they can move the answer.

1. The value of $k$. This moves the saving from 42 KB to 126 KB, a factor of 3. It is by far the largest swing, and it is the one I have no data for. If the true $k$ is near 0.9 (a page that is nearly all framework), the saving reaches 151 KB, or 27.8% of 543 KB. If it is near 0.1, the saving is 17 KB, or 3.1%. A direct measurement of framework bytes on framework-using pages would settle this.

2. How the crawl labels CDN-hosted frameworks. The Third Parties chapter defines a third party as a different site from the one visited [2]. A React file loaded from a public CDN is on a different site. If the JavaScript chapter uses the same rule (I did not verify that), then those framework bytes sit in the third-party column, not the first-party one. That would make $f$ too small and the framework saving larger than my table shows. The same chapter treats CNAME cloaking as first party [2], which pushes the other way. The sign of this error is unknown. This is also the CDN problem from my survival post, seen from the weight side.

3. Medians do not add. The 2.7% gap at the median is small. I have not checked whether the gap grows at the 90th percentile, where the two columns are most skewed. The third-party column reaches 1,292 KB there [1], so a pair of 90th percentile values describes pages that are heavy in two different ways.

A fourth issue is smaller, but I list it: the sample is home pages. Inner pages in the crawl run slightly lighter in at least one secondary report, and I could not verify that against the primary source, so I do not use it.

What I conclude, and what changes

The data supports a narrower claim than the one I often make. Third-party code is about 69% of median script bytes, so "no framework" cannot, on bytes alone, bring a typical page near the 18 KB HTML size [3]. The earlier 30x ratio is still true as a ratio (558 / 18 = 31, hand arithmetic). But most of that 31x belongs to code the site's team did not write.

My position was that most content sites would load faster and break less without a framework. Bytes are not load time, and I have not measured load time here. The byte evidence leaves the direction intact and shrinks the size: the framework is a minority of the problem at the median. I lower my confidence from 0.60 to 0.55. This is an opinion update, not a measured one.

The part of my view that survives is simple. A team that deletes its framework and keeps its tag manager has done the smaller half of the job. 92% of pages include a third party [2], and each one sits outside the author's control.

What would change my mind: a query of framework-using content pages that reports first-party framework bytes directly. If the median is above 126 KB (my upper bound), the framework matters more than I now think. If it is under 42 KB, the "no framework" case is weaker still.