The Web Has Been Quietly Bulking Up for Decades

Thirty years ago, the median web page weighed around 200 kilobytes. Today that number sits at roughly 2.5 megabytes — a 12-fold increase that HTTP Archive data, analyzed by writer and developer Nick Borș, shows climbing in an almost unbroken line across both desktop and mobile. That trajectory is not a series of accidents. It is the accumulated outcome of deliberate product decisions made at every layer of the web stack.

The growth is not coming from richer articles, sharper photos, or longer videos. Those content types have actually become more efficient as compression and encoding improved. The extra weight comes from somewhere else: bloated JavaScript bundles that ship entire application frameworks to render a single blog post, surveillance-grade tracking scripts that phone home to dozens of ad-tech endpoints before a user reads a single sentence, and third-party tag stacks that a site’s own engineers often cannot fully audit. Page bloat, in other words, is a revenue infrastructure problem dressed up as a technical one.

That distinction matters because mainstream coverage of web performance consistently misframes it. Slow load times get reported as a developer oversight — something a better build tool or a smarter caching strategy can fix. That framing lets the actual decision-makers off the hook. The product managers who approved the retargeting pixel, the executives who signed the data-broker contracts, the ad networks whose creatives arrive pre-stuffed with fingerprinting code — none of them appear in the average article about page speed optimization.

Page weight gain is a business model made visible in kilobytes. Every unnecessary megabyte represents a choice to extract value from a visitor’s bandwidth, battery, and time rather than deliver value to them. On slow mobile connections and budget hardware — the actual conditions for billions of web users — that extraction has real costs. Understanding web bloat as a structural feature, not a performance bug, is the starting point for understanding why fixing it requires more than minifying your CSS.

What Page Weight Actually Costs — Beyond Slow Load Times

The median webpage now weighs around 2.5 megabytes — roughly 130 times heavier than the ~200KB pages that defined the early web. That number doesn’t stay abstract for long once you apply it to real people paying real money for data.

In Brazil, India, Nigeria, and across rural America, metered mobile connections are the default, not the exception. When a news article or government form costs a quarter-megabyte just to load its tracking scripts before serving a single useful word, users on prepaid data plans absorb that cost directly. Page bloat is a regressive tax. It charges the people with the least to subsidize the analytics dashboards of the people with the most.

The environmental ledger looks just as grim. Every transferred byte demands energy — from the origin server, from the routers passing packets along backbone infrastructure, and from the device battery draining in someone’s hand. Multiply a single bloated page request by billions of daily sessions and the aggregate carbon footprint of unnecessary JavaScript bundles, redundant web fonts, and uncompressed images becomes a genuine climate consideration, not a rounding error.

Businesses bear their share of the damage too. Page weight correlates directly with bounce rate: users who wait more than three seconds for a page to respond abandon it at dramatically higher rates, and those abandonment events cost the site conversions it will never recover. The cruel irony is that most of the scripts adding that weight — third-party ad tags, affiliate trackers, behavioral analytics tools — were installed precisely to improve commercial performance. Because each vendor optimizes only for its own payload and nobody owns the aggregate cost, the bloat compounds with no single party accountable for the total.

The incentive structure actively resists correction. A tag management team measures its success by the data it collects, not the milliseconds it adds. A marketing platform has no contractual obligation to stay lean. The user, the environment, and the business’s own conversion rate absorb the externalities instead.

The Lean-Page Counterculture: Small Is a Design Choice

Nick Borș practices what he preaches. His article on web page bloat — the one making the rounds among developers who care about this stuff — loads in 447 KB. That number is deliberate. The piece includes data visualisations built with R’s tidyverse meta-package, the kind of work that modern publishing platforms routinely bury under megabytes of tracking scripts and framework overhead. Borș buries nothing. The page is the argument.

That argument has found an audience. Around the “sherbert” open repository, a loose community of developers is building lightweight publishing infrastructure and sharing it freely. Coordination happens on Discord, pull requests get reviewed and merged within roughly ten minutes of approval, and anyone can contribute an article directly. The tooling is the point: low page weight stops being a personal discipline and becomes a repeatable default.

The movement draws from earlier traditions — web sustainability advocates who mapped digital carbon costs to server load, and brutalist web designers who stripped interfaces down to raw function. What gives the lean-page push new urgency now is generative AI. Large language models produce text at industrial scale, and the pages hosting that content tend toward heaviness: auto-generated markup, redundant assets, analytics stacks built to monetise attention rather than serve readers. If the median page weight has already climbed from roughly 200 KB in the mid-1990s to 2.5 MB today — a 130x increase that no honest measure of content quality justifies — AI-generated content threatens to accelerate that trajectory.

Lean-page advocates are not nostalgists. They are making a technical and ethical case that page size is a design decision, not an accident. Smaller pages load faster on low-bandwidth connections, consume less energy per request, and force publishers to choose what actually belongs on a page. In a web increasingly shaped by automated content generation and surveillance advertising, that choice is a political act as much as a technical one.

What the Data Actually Shows — and What It Can’t Tell Us Yet

The HTTP Archive has tracked page weight across millions of URLs for over a decade, making it one of the few datasets capable of showing long-term trends in web performance with real longitudinal depth. Nick Borș draws on this dataset directly, and the headline number is stark: the median webpage has ballooned from roughly 200 kilobytes in the mid-1990s to around 2.5 megabytes today — a 12x increase that no corresponding leap in content quality justifies.

That median figure, though, does quiet work that flatters the industry. A handful of genuinely lean sites — personal pages, minimalist tools, text-first publications — drag the average downward and make the overall picture look more moderate than it is. Strip those out and the long tail tells a different story: the heaviest pages are getting heavier faster, loading JavaScript bundles, third-party trackers, and autoplay video that users never requested. Web bloat isn’t distributed evenly; it compounds at the bloated end.

The HTTP Archive also has a structural blind spot. It crawls publicly accessible pages, which means it captures editorial sites, e-commerce storefronts, and marketing landing pages reasonably well. It largely misses app-like experiences sitting behind login walls — dashboards, SaaS platforms, social feeds — which tend to be even more resource-intensive. The true median page weight, accounting for where people actually spend their time online, is almost certainly higher than any published figure suggests.

None of this data reaches end users in any meaningful form. There is no standardized page-weight label, no browser-native indicator that tells someone they just loaded 8 megabytes of markup to read a 400-word article. Energy consumption, data costs, and load time on low-bandwidth connections remain invisible at the point of use. Without that transparency, market pressure to reduce website file size stays weak. Developers who care about website performance optimization already know the numbers. Everyone else is browsing in the dark.

Why This Moment Is Different — and What Could Actually Change

Three forces are converging right now that didn’t exist in combination five years ago, and together they create real pressure on bloated pages for the first time.

Browser vendors and search engines have started exposing page weight as a user-facing signal. Google’s Core Web Vitals tie loading performance directly to search rankings, meaning a heavy page pays a concrete SEO penalty. Safari surfaces energy-impact indicators that flag power-hungry tabs to users. These aren’t internal engineering metrics — they’re accountability mechanisms baked into the software billions of people use every day. Developers who once treated JavaScript bundle size as a private concern now watch it influence traffic numbers.

Regulation is doing unexpected cleanup work on the advertising layer. The EU’s GDPR enforcement and the Digital Markets Act have forced publishers operating in Europe to strip or gate the third-party tracking scripts that account for some of the densest payload on the modern web. Consent management overhead is real, but the net effect in compliant implementations is measurable page weight reduction. Privacy law is accidentally becoming performance policy.

The community publishing platform built around Nick Borș’s Size Does Matter piece demonstrates that the lightweight alternative scales. The platform accepts article contributions through pull requests to an open repository, runs without a heavyweight CMS, and typically deploys approved changes within ten minutes. Borș’s own piece loads at roughly 447 kilobytes — in a web environment where the median page weighs around 2.5 megabytes, that number is a statement. The workflow is collaborative, the output is accessible, and nothing about the architecture requires the bloat that corporate publishing stacks treat as inevitable.

What makes this moment different is that the pressure is now coming from multiple directions simultaneously. Rankings, battery life indicators, privacy regulation, and working proof-of-concept lean platforms are all pointing the same way. Page weight reduction is no longer just a performance optimization talking point — it has legal, commercial, and environmental dimensions that make ignoring it increasingly expensive. The question isn’t whether lightweight web design is viable. It’s whether the industry’s financial incentives will shift fast enough to let it win.

What Readers and Developers Can Do Right Now

The tools to audit page bloat already exist, and most of them are free. Open any browser’s developer console, click the Network tab, and reload a page — you will see exactly how many requests fire and how many kilobytes cross the wire. WebPageTest goes further, breaking down load time by asset type and geography. The HTTP Archive publishes its entire dataset publicly, giving anyone access to the crawl data Nick Borș used to chart the web’s growth from a ~200KB median page weight in the mid-1990s to roughly 2.5MB today. A problem that once felt abstract becomes measurable in under five minutes.

Developers have a shorter path to meaningful impact than they might think. Choosing a minimal framework over a bloated one cuts JavaScript payloads before a single line of application code is written. Self-hosting fonts eliminates the third-party DNS lookup and render-blocking request that Google Fonts introduces on millions of sites. Auditing third-party scripts — analytics beacons, chat widgets, ad tags — often reveals that a page is carrying four or five external dependencies for features that deliver marginal value. Each removal shows up immediately in the Network tab as reduced transfer size and faster time-to-interactive. These are not aesthetic preferences; they are engineering decisions with documented, measurable outcomes.

Readers carry more leverage than the industry acknowledges. The platform Borș writes on — Sherbert — operates as a community publishing space where contributors submit articles via pull request and pages load at around 447KB, demonstrating that functional, readable web publishing requires a fraction of the bandwidth most commercial outlets consume. Platforms like this thrive when readers share, link, and return to them. Traffic patterns are data that larger publishers track obsessively. When lightweight, fast-loading sites accumulate loyal audiences, they create a market signal that performance and respect for users’ bandwidth translate into engagement — the one metric no editor or product manager ignores.

Page weight reduction, web performance optimization, and lean web design are not niche concerns for developers alone. They are decisions that shape who can access information, how much energy the internet consumes, and whether the open web remains usable on the hardware most people actually own.