Why Browsers Keep Getting Heavier Every Single Year

Isolation multiplied everything

Since the Spectre-era hardening, Chromium runs each site in its own process, and Firefox followed with its own per-site split. A fifteen-tab session with a few extensions is easily twenty-five processes and counting — the browser, the GPU process, the network service and one renderer per site. Site isolation is genuinely good security: a compromised renderer cannot read another site's data. But every process pays full price for the rendering stack, so the same fifteen tabs that shared one process in 2014 now pay the entrance fee fifteen times.

Extensions are processes too. Since Manifest V3 they run as event-driven service workers, waking when their rules need them and keeping content scripts injected into every page you open. A dozen "small" extensions is the memory weight of several extra tabs, and a single misbehaving one can out-eat them all. Chrome's built-in task manager (Shift+Esc) shows the per-tab and per-extension cost with names attached — five minutes there beats any generic advice.

The platform only ever grows

A browser ships the same binary to everyone, and it carries everything the modern web can do: WebGPU, WebAssembly, WebRTC, WebCodecs, service workers, installable apps. Feature removal is nearly impossible — somewhere, a bank or an intranet still depends on the API from 2013 — so the engine only accumulates. Each release also updates its components in the background: codecs, the networking stack, safe-browsing lists; the browser you never restarted yesterday patched itself three times.

The web pages themselves grew just as fast. An average page now ships megabytes of JavaScript before content is visible, ads and analytics piggyback on top, and a "light" news site easily loads a hundred scripts. The browser is honest about whose weight it is carrying — open the built-in task manager and compare one document page against one shopping site. The engine got heavier, but the payload grew faster.

• A full JavaScript engine with JIT — every process pays for the compiler, not just script-heavy sites
• GPU compositing and codecs — each renderer carries its own share of the graphics pipeline
• Service workers — sites keep logic running in the background with no visible tab
• Installable PWAs — a web app gets its own runtime, indistinguishable from a small browser
• Extensions — a process each, plus content scripts injected into every page you open

What actually reduces the bill

The honest first step is tab suspension, and it is built in: Edge's sleeping tabs freeze background tabs on a timer you control, and Chrome's Memory Saver unloads inactive tabs and restores them on click. Both recover real memory, and both let you pin exceptions for sites you want always-live. The second step is an extension audit: remove what you do not recognize, disable what you use weekly instead of hourly, and watch the task manager numbers before and after.

What does not work: chasing "light" browsers. Anything running the same engine carries the same per-process architecture and the same platform weight — you trade compatibility or security updates for a rounding error. Old forks on abandoned engines are worse than heavy: they are unpatched attack surface. More RAM is the unglamorous fix that actually matches the trend line — the browser is an operating system for the web, and nobody runs an operating system on the minimum spec.

Questions and Answers

Read next