Stop the presses: Has the average web page actually gotten SMALLER?

According to the HTTP Archive, the average top 1,000 web page is 1491 KB in size, 5% smaller than it was six months ago, when the average page reached a record size of 1575 KB.

But let’s not start celebrating yet.

Does this finding represent the start of a new trend toward smaller pages, or is it just an isolated incident? To answer this question, we need to take a look into the Archive’s other findings.


HTTP Archive: Page growth

1. The average top 1,000 web page is 1491 KB, down from 1575 KB six months ago.

Yes, this represents only a 5% decrease in page size, but after watching pages explode over the past three years, any news about smaller pages seems like good news. But as I’ve already said, let’s not put on our party hats just yet.


2. The only content type that experienced significant shrinkage was “other”.

The “other” content type is a bit of a grey area. As the graph below indicates, it surged dramatically in size in late 2012, when the HTTP Archive changed the way it gathers data. Prior to the change, the tests stopped at document complete (windows onload). Afterward, the tests ran until the end of network activity, which increased the size and number of requests per page, and which led to an increase in the catch-all “other” category. The best guess is that this category includes video and third-party content.

Let’s try to understand why “other” content has shrunk by more than half — from 262 KB last November to 121 KB now. It’s unlikely that this shrinkage is due to any decrease in third-party content, since by all accounts, third-party scripts are on the rise. (Steve Souders recently shared findings that third-party calls can make up more than 50% of page requests.) So ruling out third-party content leaves us speculating that either the shrinkage is due to a decrease in use of video (quite possible) or an undocumented change in the testing process (somewhat possible).


3. Growth due to images is rampant.

We’re in love with images. Right now, they comprise a whopping 57% of the average page’s weight. Six months ago, images comprised 51% of a page’s weight.

If our love affair with images is only going to increase — and I’m sure it will — we need to get a handle on how we use them. Images are a major performance hurdle. Too often, they’re in the wrong format or uncompressed or unoptimized — or all three. We can do much better.

HTTP Archive: Page growth due to images

4. Custom fonts have overtaken Flash.

The graph below beautifully illustrates an aspect of the human condition that I find both amusing and frustrating: You can count on the fact that if you have a team of geniuses in room A working to fix one problem, there will be a team of equally brilliant people in room B developing a technology that will create a new problem.

In this case, we see how sites are dropping Flash from their pages, thereby negating one type of performance problem. But then along came custom fonts to create a brand-new set of performance challenges. See that point where the two lines intersect? That point represents the crux of the problem with our great big hominid brains.

(Note that custom fonts don’t have to be performance bad guys. See here and here for tips.)

HTTP Archive: Flash and customs fonts

Conclusion: Is this page size decrease a trend or just a one-off?

I’m inclined to take the pessimistic view that this is an isolated incident. Given that almost every other content type is on the rise — particularly images and custom fonts, both of which can incur major performance penalties — their growth will ultimately overshadow the minor win we’re seeing right now with the decrease in “other” content types.

Also bear in mind that smaller pages don’t necessarily mean faster pages. While egregiously large payload is definitely a contributing factor to slow load times, there are other variables — such as sluggish third-party content — that can slow down or block a page from rendering. And as our own research has found, many site owners are failing to build pages that render key content first, a critical user experience flaw.

Related posts:

Tammy Everts

As a former senior researcher, writer, and solution evangelist for Radware, Tammy Everts spent years researching the technical, business, and human factor sides of web/application performance. Before joining Radware, Tammy shared her research findings through countless blog posts, presentations, case studies, whitepapers, articles, reports, and infographics for Strangeloop Networks.

Contact Radware Sales

Our experts will answer your questions, assess your needs, and help you understand which products are best for your business.

Already a Customer?

We’re ready to help, whether you need support, additional services, or answers to your questions about our products and solutions.

Get Answers Now from KnowledgeBase
Get Free Online Product Training
Engage with Radware Technical Support
Join the Radware Customer Program


An Online Encyclopedia Of Cyberattack and Cybersecurity Terms

What is WAF?
What is DDoS?
Bot Detection
ARP Spoofing

Get Social

Connect with experts and join the conversation about Radware technologies.

Security Research Center