Browsers are becoming more bloated

Published on 28/08/2026
Updated on 31/08/2026

Modern browsers are among the most complex pieces of software in the world and they are basically operating systems disguised as applications. They are so complex that writing one from scratch is not feasible even for a company like Microsoft.

Browser vendors have to keep adding new features in order to keep up with ever-growing web standards. This has a cost of increased complexity of the codebase and binary size bloat. Binary size bloat is an engineering concern in Chrome, Firefox, and WebKit/Safari that few people talk about.

How bad is browser bloat and what are the consequences?

In order to illustrate the bloat problem, I compiled Chrome size changes for the last 5 years:

In its installed form, Chrome went from roughly 250 MiB to 420+ MiB in 5 years.

OK, people might say that it's not a problem, disk space is cheap, right? Well, browser teams care about it also for reasons beyond the size on the disk. A larger binary also means more:

• Instruction cache pressure
• Page faults
• Memory mappings
• Relocation work (the work the OS loader has to do when loading an executable or shared library whose code/data contains addresses that can't be finalized until load time)
• Cold start IO
• Download bandwidth
• Patch generation difficulty
• Attack surface and maintenance burden

All browser vendors care about these problems. For example, Mozilla has automated performance infrastructure that tracks installer size regressions. In May 2025 Firefox's automated systems opened a performance regression bug because a change increased installer size by 11.1%.

One WebKit investigation found that shrinking code produced an unexpectedly large performance benefit. Their explanation was that binaries were growing faster than CPU caches and memory performance could compensate, increasing instruction cache misses, TLB misses and page faults.

What can be done with this increased bloat?

Because of the insane complexity, some growth is genuinely the cost of implementing a continually expanding web platform. When we have CSS engines powerful enough to implement an x86 emulator, this is not surprising at all.

There is also a "tragedy of the commons" effect. An engineer adds a feature that adds 200 KiB to the binary and reasonably concludes that 200 KiB is irrelevant. Meanwhile, another team adds 500 KiB, another library adds 1.2 MiB, another UI feature adds 300 KiB, and so on. The accumulated effect is now enormous.

Perhaps we should slow down the expansion of web standards and focus only on the most essential things. Do we always need to add yet another small cool CSS feature instead of delegating to libraries / frameworks? There were indeed some fundamental recent features that I can appreciate, such as:

• Nested CSS selectors
• @container rules / units
• selector argument of :nth-child(<position> of <selector>)
• :has() pseudo-class

But the total number of the CSS features is overwhelming and terrifying, just look at the Houdini API. The same is true for some other things. I'm worried that this might start to slowly collapse at some point... From both maintenance and performance points of view.

We have only 3 major independent browser engines (the others are largely derivatives or old / understaffed projects which are not competitive): Chrome, Firefox and Safari. Because of the insane complexities of modern web standards, we are unlikely to see browsers with brand new engines. Browser engine diversity could even shrink if an existing browser engine becomes underfunded and / or loses a critical number of users / web developers, like Firefox. And that's not good...

See you later.