In 2010, the average web page weighed about 702 kilobytes. Today, that number sits somewhere north of 2.5 megabytes — and that's the average. News websites, retail pages, and media properties regularly clock in at 10, 15, even 20 megabytes of data transferred before you've read a single sentence.
Think about what has actually changed on a news article page in that time. There's a headline. Some paragraphs. Maybe a photo. Possibly a video. The fundamental content of a news article in 2024 is not meaningfully different from a news article in 2010. And yet your browser is working harder to display it than a mid-range laptop from that era could even theoretically manage.
Something went very wrong. Several somethings, actually, and they all have business cards.
The Invisible Passengers on Every Page Load
Open your browser's developer tools on a major news website — any of them, pick your favorite — and watch the network tab as the page loads. What you'll see is a cavalcade of requests that have absolutely nothing to do with the article you came to read.
There's the Google Analytics call. The Adobe Analytics call, because this company apparently needed two analytics platforms. There's a Chartbeat request tracking your scroll position in real time. There are calls to three separate advertising networks, each of which triggers its own cascade of sub-requests to demand-side platforms, data management platforms, and identity resolution services that are attempting to match your browser fingerprint to a profile they already have on you.
There are A/B testing scripts from Optimizely or VWO that need to decide which version of the page to show you before showing you any version of the page. There are tag management containers — Google Tag Manager, Tealium — that exist to load other scripts, which are themselves sometimes tag managers loading more scripts, a nesting doll of JavaScript that would be funny if it weren't happening on a device you paid for using bandwidth you're paying for.
A 2023 analysis of the top 1,000 websites found that the median page made 65 third-party requests. Not 65 total requests. 65 requests to domains that are not the website you actually visited. You asked for one thing. You got 65 things.
The Framework Problem Nobody Wants to Talk About
Front-end development has undergone a genuine revolution in the last decade, and like most revolutions, it created some collateral damage.
Modern JavaScript frameworks — React, Angular, Vue, and their various descendants — are powerful tools that enable sophisticated, interactive web applications. They are also, when deployed to serve a static article about, say, the best hiking trails in Colorado, the equivalent of hiring a full construction crew to hang a picture frame.
The phenomenon known as 'JavaScript bloat' is real and well-documented. A React application ships a substantial runtime to the browser even before it renders a single pixel of your actual content. Server-side rendering helps, but many development teams either don't implement it correctly or don't implement it at all, resulting in pages where your browser downloads a large JavaScript bundle, executes it, and then starts building the page you could have received as simple HTML in the first place.
This isn't a knock on developers, most of whom are working within constraints set by organizations that chose their tech stack based on what's fashionable, what their engineers already know, or what a vendor sold them at an enterprise conference in 2019. The problem is structural: the industry normalized heavyweight frameworks for use cases that don't require them, and now the entire web is paying the performance tax.
Ads That Load Ads That Load Ads
Programmatic advertising deserves its own chapter in whatever future historians write about the internet's decline, but let's keep it to a section.
When you load a page with programmatic ads — which is to say, almost any page on a major publisher's website — what happens in the background is genuinely staggering. The page calls an ad server. The ad server runs an auction among dozens of demand-side platforms. The winning platform loads its creative. That creative often contains its own tracking pixels. Those pixels fire requests to data brokers. The data brokers respond with audience segments. Some of this happens sequentially; some in parallel; all of it is happening while you're waiting to read about the hiking trails.
The industry term for when ads slow down page rendering is 'render-blocking,' and it's been a known problem since approximately forever. Google's own Core Web Vitals initiative — the set of performance metrics it uses as ranking signals — was explicitly designed in part to pressure publishers into fixing it. The pressure has produced some results. It has not produced clean, fast pages, because the financial incentive to load one more ad unit remains stronger than the performance incentive to load one fewer.
Who Pays the Price
Web bloat is not a problem that affects all users equally, and this is where it stops being merely annoying and starts being something worth getting genuinely angry about.
Users on high-speed fiber connections in dense urban areas experience bloated pages as a mild inconvenience — a slightly longer load time, a brief flash of layout shift. Users on mobile connections in rural areas, or on older devices, or on capped data plans, experience those same pages as a meaningful barrier. A 15-megabyte page load on a 4G connection in a rural county isn't just slow. It costs actual money. It consumes a measurable portion of someone's monthly data allowance to deliver content that could have been served in 200 kilobytes.
The web's accessibility problem is usually framed around screen readers and color contrast. Page weight is equally a form of access inequality, and it receives a fraction of the industry conversation.
The Web That Could Have Been
Here's what's maddening: we know how to build fast websites. The technology isn't the problem. Plain HTML and CSS remain extraordinarily capable. Static site generators can produce blazing-fast pages with minimal JavaScript. Image compression tools are excellent. Content delivery networks are cheap.
The websites that consistently score highest on performance benchmarks are often the simplest ones — plain text blogs, documentation sites, small independent publishers who never had the budget for enterprise tag management suites and accidentally ended up with better user experiences as a result.
The web got slow because slowness was profitable. Every tracking script, every ad network, every analytics platform added a line item to someone's revenue report or justified someone's departmental budget. The user's time was never a cost that appeared on any of those spreadsheets.
Until it starts showing up there, your browser is going to keep sweating.