Skip to main content

Bits.

For a few years now, our industry has framed the problem with web performance primarily as a problem of flawed practices: namely, that digital teams don’t know that their web pages are too heavy or too slow. (Or worse, that they don’t care.) As a result, we’re left with web pages that were simply not well-made—they’re too slow to load, and too expensive to download. If we follow that logic a bit further, it seems reasonable to expect that if we can improve awareness around performance, then we’ll improve the quality of the decisions those teams make. That’s why we evangelize the clear business and economic benefits for building faster websites; we talk about emerging markets, and how they use the web; we talk about the need for designing with a performance budget; and so on.

This is all good, and necessary, and sorely needed. But looking at the web’s performance solely through the lens of process misses a number of larger, more structural problems. And if we want a faster web, we have to talk about performance in a broader context.

While writing this, I disabled my ad blocker, and visited the homepage of a popular American news site. I watched my browser’s network panel download a few megabytes (megabytes!) of stuff, roughly two-thirds of which was JavaScript: code that’s used to load advertisements, tracking scripts, and analytics software. JavaScript is great, of course, but it’s also one of the most expensive things to put on a web page. And on this one page in particular, there’s just so danged much of it.

I’m guessing you’ve seen a few pages like this—probably more than a few today, even. It’s tempting to place the blame for those pages at the feet of the product teams that manage them, and to ask why they’re not making better decisions. But let’s refocus for a second: why is that code there?

Well, it’s there to generate revenue. Regardless of what you or I might believe about the merits of online advertising, or the ethics of surveillance capitalism, that code keeps the lights on. A beacon might have to be included because of an advertising partner’s contract. A script might be on the page because it’s syndicating sponsored content from a third-party source. And while we might lecture a working web developer about the ethics of shipping a web page with tracking scripts, those scripts very likely help pay their salary.

Yes, the web is far, far too slow. We should talk about digital design practices that could be better, and advocate for change. But ultimately, the web’s performance problem is a problem of profitability. If we’re going to talk about bloated pages, we should do so in context: in the context of a web where digital advertising revenue is cratering for publishers, but is positively flourishing for Facebook and Google. We should look at the underlying structural issues that incentivize a company to include heavy advertising scripts and pesky overlays, or examine the market challenges that force a publisher to adopt something like AMP.

In other words, the way we talk about slow websites needs to be much, much broader. If we can do that, then we’ll have a sharper understanding of where—and how—the web can be faster.


Current page