I’ve been tracking the size and composition of the top million websites (thanks to the HTTP Archive) since 2011. Back in 2012, it was huge news when the average page exceeded 1 MB. At the time, people were incredulous… and even outraged. And they almost immediately began to speculate about when the average page would crack the 2 MB barrier. It looks like the speculation can end now.
1. The average web page is 2099 KB
As of May, the average web page surpassed the 2 MB mark. This is almost twice the size of the average page just three years ago.
The graph below gives a breakdown of where all those kilobytes are going. You can see that pretty much every asset type is in growth mode, with the most notable ones being images, scripts, and video content.
This entire graph is put into insane perspective when you consider that back in 1995, the average page was 14.1 KB. In other words, the average page today is almost 150 times larger than the average page twenty years ago.
2. Images comprise 62% of a page’s total weight.
Images account for almost two-thirds of the average page’s total girth.
To put this in another perspective, it’s incredible to note that today, images alone comprise more page weight (1310 KB) than an entire page in May 2012 (1059 KB), just three years ago.
As internet users, we crave images — the bigger, the better. Site owners play to this craving, knowing that serving bigger, better images has a direct impact on conversion rate (the percentage of site visitors who convert to active customers) and other business metrics. For example, Dell ran an A/B test in which they super-sized the hero image on a landing page. The huge image experienced a 27% lower bounce rate and a 36% increase in lead generation.
But as developers, content creators, and site owners, images cause us no end of performance-related angst. The vast majority of images on the web are unoptimized — uncompressed, unconsolidated, incorrectly formatted, and wrongly sized. Here’s an image optimization checklistI created a few months back to get you started with introducing the importance of image optimization to everyone in your organization (particularly non-developers). For a deeper dive, I highly recommend that you sign up for Guy Podjarny’s upcoming O’Reilly webinar, High Performance Images. (Guy also has a book coming out, which will tackle this topic in even greater depth.)
3. The popularity of custom fonts isn’t slowing down
Every time I write about page bloat, I like to show an updated version of this graph, which documents the rise of custom font usage alongside the decline of Flash. Why? Because it perfectly illustrates the kind of difficulty our juicy hominid brains get us into: just when we’ve begun to phase out one technological hurdle, we introduce a new one.
I should clarify that I don’t think custom fonts are bad in and of themselves. I completely appreciate the fact that they give designers and site owners 100% control over their brand visuals. (This isn’t trivial, in a age where some fonts have become inextricably linked to certain brands.) But when custom fonts are poorly implemented or hosted externally, this introduces the potential for performance pain. To wit, waterfall charts that look like this:
Ilya Grigorik has written an excellent post about webfont optimization, which is a must-read for designers and developers.
Projection: 3 MB pages in 2017?
So this news leads to the inevitable question: when can we expect pages to hit 3 MB? Looking at the numbers over the past two years, I calculated that page size increases by 8% every six months. (This is a conservative estimate.) As the graph below shows, we can extrapolate that the average page could exceed 3 MB in late 2017 — just two and half years from now.
But isn’t the internet getting faster?
Inevitably, some people respond to these page growth reports with the argument that page bloat is somewhat acceptable because it’s mitigated by other factors, such as faster networks and smarter browsers.
While browser vendors have done a great (and mostly thankless) job of helping to mitigate the performance woes caused by rampant page growth and insane page complexity, browsers aren’t keeping up with page demands. To illustrate this, Radware has been tracking the load times of the top 100 retail websites on a semi-annual basis for several years and has found that both load times and time to interact have suffered significantly. In 2012, the average page took 7.1 seconds to load in Chrome 20. In 2015, the average load time had increased to 10.4 seconds for pages tested in Chrome 40.
As for the “better, faster networks” argument, I recently talked about why faster networks don’t equate to blazing load times, demonstrating that increasing bandwidth by 300% results in only a 24.6% page speed improvement. So yes, while more bandwidth helps, it’s not a performance cure-all.
How big should pages be? Ideally, around 1 MB.
In a survey (which I referenced in this talk I did at the Conversion Conference last month) of 60 popular responsively designed pages, only 20% of the pages loaded within an acceptable amount of time. The one thing all the faster pages had in common: they were are under 1 MB in size.
Not coincidentally, 1 MB is the size that many companies are establishing as the top end of the “performance budget” they set for their pages. (If you’re unfamiliar with the idea of a performance budget, Tim Kadlec has written some posts here and here that do a great job of spelling out why you need a performance budget and what kinds of metrics you should track.)
Takeaway
Page size isn’t the only factor that can slow down your pages. There are numerous other potential problem areas: latency, page complexity, server load, slow database queries, and so on. But page size should be on every site owner’s radar.
The difference between a 2 MB page and a 1 MB page can mean several precious seconds added to a page’s load time. We know that making pages just one second faster can correlate to conversion increases of 9% or more. Putting your site on a diet is the first step toward making these conversion gains.