Web pages are getting more bloated, and here’s why

Posted in Tech blog on November 21st, 2011 by Pingdom

Over the past year, web pages have on average become 25% bigger. We’re not talking about dimensions here, but download size. Based on the top 1,000 websites on the Internet, the average page size has gone from 626 kB to 784 kB.

A 25% size increase in just one year is rather drastic. With that kind of growth, the average web page will be 980 kB in just a year (amost 1 MB!). In five years, a page will be almost 2.4 MB. And that’s just an average, many pages will be significantly larger.

What is behind this exploding growth? Let’s find out.

The size increase by content type

We honestly didn’t expect the trend to be quite this noticeable, but it’s indeed what has happened according to the HTTP Archive website, which runs a monthly batch of tests on a large number of websites. It’s a great initiative, an archive for how web technology changes over time. Now that it’s been operating for a while it’s starting to really show its usefulness. This entire article is based on HTTP Archive data.

We’ve analyzed the data from the HTTP Archive and put together a couple of very telling charts for you. You actually only need to look at these charts to solve “The Mystery of the Expanding Websites” (coming soon to a theater near you).

Web page size change in one year

Images have always been, and continue to be, the biggest single factor to page size. Their contribution to page size has also increased the most if you look at sheer size.

That part we kind of expected, but there is something else going on here as well. Things become really interesting when you look at relative growth per content type.

Web page content size change in percent

So there you have it. Those two charts together = mystery solved.

In terms of sheer size, images are still the biggest factor, but the fastest-growing content type by far is JavaScript. It is also the second-largest content type in terms of size.

CSS content has increased 25% in size, which may seem like a lot, but we are still talking about relatively small files. That increase doesn’t matter as much. It does matter, though, that every single content type is growing. Size optimization seems to have gone out the window pretty much across the board.

On a side note, the number of requests it takes to load the average web page has also increased, but not as dramatically. It’s gone up from 77 to 87 (13%).

JavaScript and the bite of the HTML 5 bug

So, you may wonder, why has JavaScript usage seemingly exploded?

The drastic increase of JavaScript content is most likely tied to the rise of HTML 5, with websites using JavaScript as an increasingly important part of a dynamic web experience. You could say that JavaScript is finally starting to live up to its potential.

There is a reason Google, Mozilla, Microsoft and Apple are all optimizing their JavaScript engines as much as they can. Web developers are doing much more with JavaScript now than they did just a few years ago.

Why care about page size?

A very good reason to keep page sizes down if possible is that you can’t always count on your visitors sitting behind awesome, high-speed broadband Internet connections that make your lumpy site fly.

Believe it or not, there are still people on dial-up out there. Even if they are a minority today, they do exist, and you may not want to make it impossible for them to use your site.

Then you have all those people with low-end broadband connections. Those make up a huge part of the Internet.

Don’t forget that people shy away from slow-loading websites. That has been proven over and over again. If anything, people are becoming more demanding every year. Just look at your own web surfing habits and you’ll know this is true.

An example: Surfing the Web via a 3G modem of some sort (or tethered to a smartphone) is becoming increasingly common, especially for people on the road but also at home. A basic 3G connection (no Edge, LTE, etc.) will give you a download speed of 384 kbit/s. Yes, it’ll usually be faster these days, but not always. That will let you download roughly 48 kB per second. It takes 21 seconds to download 1 MB at this speed, but to that you have to add the overhead of the multiple requests a browser has to perform to download a page. If it takes less than 30 seconds, we’d be surprised.

A side benefit of having a more optimized site is that it usually means less work for your web server, so you’ll be able to handle more visits at once. And you’ll save money on data transfer costs (if you’re paying for that).

What can you do?

The first thing to do is to be aware of the problem. How big is your site? Do you know? And if it is unnecessarily big, what is it that contributes the most to that bulk?

Size is of course only part of the “performance formula” for a website. But it’s often an important one, especially if you’re targeting users that won’t necessarily have optimal Internet connections.

There are plenty of freely available tools out there that can help you analyze and optimize the size and performance of your website in various ways. There is the famous Yslow from Yahoo, or Page Speed from Google. These will do the tests locally on your own computer and give plenty of helpful metrics and even advice.

Another super-easy way is to use one of the web-based page size analyzers that are out there. They do their tests from servers on the Internet. Pardon the plug here, but we are partial to our own Full Page Test in Pingdom Tools. There are also others you can check out, like WebPageTest.org.

No excuses

As we pointed out, today’s main culprits to large page sizes are images and JavaScript files. This survey focused on the top 1,000 websites because we wanted to prioritize the sites people spend the most time on. The overall trends shown in this article are actually even worse if you include a wider sample, believe it or not.

Web pages have been growing in size all along. The Web experience is constantly getting richer, getting more content, and people in general are getting increasingly capable Internet connections. It’s a natural progression.

That doesn’t mean we should stop caring about page size, though. It’s still an important speed factor, and with today’s freely available developer tools there are so many easy ways to analyze and optimize web pages that there really are no excuses for overly bloated websites.

Tags: chart, html, html5, http, HTTP Archive, internet, Javascript, JS, optimization, report, size, study, survey, tech, webdesign, webdev, webdeveloper, webmaster, webpage, website

Did you like this post?

Related content:

23 comments

Newest | Oldest

Andrew Johnstone

The interesting part is that increasing broadband connections speed will not dramatically increase the speed at which pages will load and render. The problem is with the expense of establishing tcp connections in the first place. Additionally all browsers limit the number of simultaneous connections that can be made. As highlighted by the table below. HTTP/1.1 HTTP/1.0 IE 6,7 2 4 IE 8 6 6 Firefox 2 2 8 Firefox 3 6 6 Safari 3,4 4 4 Chrome 1,2 6 ? Chrome 3 4 4 Chrome 4+ 6 ? iPhone 2 4 ? iPhone 3 6 ? iPhone 4 4 ? Opera 9.63,10.00alpha 4 4 Opera 10.51+ 8 ? http://www.stevesouders.com/blog/2008/03/20/roundup-on-parallel-connections/ There are a number of ways that attempt to reduce tcp connections and both apply to the above. Firstly http keepalives are aimed to reduce the tcp connection overhead, additionally http pipelining aims to reduce the round trip time for http requests. http://en.wikipedia.org/wiki/HTTP_persistent_connection http://blog.amt.in/what-is-http-pipelining-why-is-it-important-f http://www.blaze.io/mobile/http-pipelining-big-in-mobile/ The other aspect is that the analysis collected is not very descriptive of what it is based on. For example, of those sites, how many were correctly using etags and gzip compression?

Pete Markiewicz

I'd be VERY interested to find historical data on web page downloads going back further than the HTTP archive (about 1 year). It seems to me that greater efficiency afforded by HTML5 and CSS3 might paradoxically lead to increased resource use, as described by "Jevons' Law" or "Jevons' Paradox" for oil and other energy consumption in the real world. Does an increase in efficiency lead to greater resource use? Comparing the web of 10, even 20 years ago to today would be VERY instructive. Was the "world wide wait" of the 1990s worse than today? Or, have we developed UX that hides increased downloads (as described in this article http://www.uie.com/articles/download_time/)

Roger Burke

Ineresting stats from Pingdom and would be a problem if they were static pages being sent for the server. What we now have is Ajax & while that may increase the javascript load it will actually decrease the traffic. Also the browser is now being used more to service pages through javascript which again reduces the traffic. So while the individual page size may be increasing, it would be interesting to see how long they stay up before being replaced.

Lennie

Something else I noticed, which in theory is a good thing but obviously impacts performance of your not using a CDN: https is used more for external resources now.

Lennie

What I really hate are the large numbers of redirects (like url shorteners) and how all these extra Javascript libraries are loaded from so many different domains. Many sites now have 10+ domains on every single page, that is just stupid. It doesn't make any sense to me. Also I have an improvement request for Pingdom, add a (optional) accept encoding gzip deflate header to your monitoring service it is more realistic.

Brian Manning

One interesting thing to see would be the relative size change of videos over that time. That's a lot of bandwidth, and people are serving higher quality videos, yet at the same time codecs are advancing and becoming more effecient. Just would be an interesting additional study for someone.

Ted Goas

has anyone mentioned Micro JS yet? Popular core JS libraries are big (jQuery, jQuery UI without customization are over 100k each. A lot of site don't use everything included in them. Using MicroJS can help ensure site authors only add what they need and don't get too much extra code. http://microjs.com/

Dan

About the JS libraries, I mean sure shims and polyfills are bad in a sense because they create overhead that shouldn't be there but it is just a fact of life if you are using a new technology. I enjoy writing jQuery, yes I can write vanilla JS. The one big thing you do with JS is interact with the DOM so to me $() or document.getElement.byId() I mean its not a huge difference until you do it 50 times then it does become a huge difference. That is only one example of write less do more. So I wouldn't really blame libraries especially if you use the CDN version it is probably cached anyway even if they are a new user so the overhead is next to nothing since you won't be using a http request unlike yoursite.com/site.js which wouldn't be cached for a new user. Unless you really need something really can't get with a library why would you bother using more kb download time as well as more development time. If I really need what vanilla JS brings I could do a large amount of it with a server side language which in turn won't hit me on initial download or processing power,granted it will hit me for a http request later on but it may be 2 or 3 in small succession instead of 20. Thanks.

Bob Myers

Isn't much of the JS cached and loaded only once for all pages on a site?

itoctopus

There are many reasons why most webpages are slow these days: - Ads, ads, and more ads (especially those inline ads that popup when you hove the mouse) - Multiple tracking tools - Integration of social networks - etc...

McCoy Pauley

JavaScript libraries are DEATH! Their users are the coding equivalent of all those granola-gobbling hippies that infest the woods these days with their giant refrigerator-sized backpacks and those faggy nylon clothes that squeak like a gutshot mouse every time they move. Thank God the grizzlies will eat them despite all that crap. Thank God the bears are DRAWN to those little bells. Man up, Emo-codebois. Learn to WRITE code and CRUNCH code, or stay the hell out of my woods AND my cyberwoods with your "indispensible gear".

Matt

Good post, there are other factors that influence this results - the average page size has increased, I am talking about the width in pixels which results in larger images being used and more content - more websites have a mobile version, so the desktop site is more bloated as it does not have to cater for the slow downloads on mobile devices - more sites use CMS systems that are built to fit all hence carry more code, the bespoke optimised solutions are replaced as they are too expensive to maintain althought they were probably lighter - the browser and device compatibility has effect as well especially as the user experience is getting reacher but we still have to support old browsers

Paul M

I find webpagetest quite useful, as although yslow and chrome's built-in page load time helps optimise, it doesn't reveal how your website loads from other places. Here's an example: http://www.webpagetest.org/result/111122_VX_291D4/1/details/

Mark

@Pingdom: Are you including bundled fonts in Images, then? 1. Could that, rather than bigger images, explain the increase? 2. Is the use of webfonts widespread enough now that we're witnessing it in these numbers? 3. Or will increased usage of webfonts cause this trend to increase even more dramatically?

Pingdom

@Mark: Can't really say, but we doubt that custom fonts are to blame (at least for the majority of the difference). They should fall in the "other" category of downloaded data (if you add up the numbers in the first chart, you'll notice there's a gap, which is a smaller "other" category of uncategorized data). Usage of custom fonts is clearly up, though. From 2% of the top 1k sites a year ago, to 8% now. http://httparchive.org/trends.php?s=Top1000#perFonts

Pingdom

Thanks everyone for chiming in with your thoughts and observations!

Josh Humble

With today’s huge frameworks and the need for complex CMS’s, I’ve certainly become concerned with site bloat. I’ve beckoned for the return of simplicity in web development for a while now. Wordpress, JavaScript, and open-source/third-party development are wonderful – WHEN practical, useful, and lean – just like it always has been. I like to keep third-party resources to a minimum, if at all, though. Not only are many still on dial-up (even though they may or may not be the target demo), too many are on “high-speed” internet that acts like dial-up. Developer humility comes when working with a crippled server or an ISP with bad coverage on several projects. Also, for images, I’m a fan of Yahoo’s SmushIt, with their loss-less compression – takes so much weight out of development. Thanks for the great post – we all need to be reminded of this more!

Mark

Are @font-face downloads included in those numbers? Particularly with multiple weights and fonts bundled via Typekit et al?

Pingdom

@Mark: They are included in the total download size numbers, but bundled fonts should not be part of the JS numbers, if that's what you mean.

John Polling

I've noticed a trend of people not compressing their CSS / JS files as much as they used to. It looks like people are find with using the packed version of jQuery plugins etc, but they forget about minimising their own assets

third party widgets and gadgets are of course the biggest culprit. they can easily add couple of seconds of load time to your webpages and facebook blocks are some of the slowest to load of all.

Mike Hudson

Another big trend I have noticed that contributes to this issue is the number of times a site will make unnecessary calls to various versions of jQuery, and not all from the same source (external, WordPress includes, plugins etc).

Ayesh

I had a quick YSlow test against my own site (not the one linked to my name above) and gone crazy seeing facebook recommendation block javascript that cost 100kb! Quickly ditched that and now it's 500kb. That site is a meme sharing site so size is balanced. site is 3mugs.com btw.

Trackbacks

Report: Web Pages are Getting More Bloated, Up 25% From Last Year — SiliconFilter says:

November 23, 2011 at 1:02 pm

[...] actually getting bigger, too. According to uptime monitoring service Pingdom, the average website grew an astonishing 25% over the last year. The main culprits here are images and JavaScript. Images now weigh in at 451 kB on the average web [...]
Average Web Page Size Grew 25 Percent in a Year | End User Personal Desktop says:

November 26, 2011 at 6:16 pm

[...] to push the envelope. And they’re clearly doing it. Pingdom, relying on HTTP Archive data, is reporting that the average web page has grown in size by 25 percent in the last year alone.When looking at [...]
Average Web Page Size Grew 25 Percent in a Year | Latest Gadgets News says:

November 26, 2011 at 6:18 pm

[...] clearly doing it. Pingdom, relying on HTTP Archive data, is exposure that the mean web page has developed in [...]
Secara Purata, Saiz Halaman Web Meningkat 25% Dalam Masa Setahun | Amanz says:

November 27, 2011 at 5:05 am

[...] pantas, membuatkan ramai pembangun mengoptimasikan saiz laman web mereka. Namun menariknya, melalui suatu kajian yang dilakukan, sepanjang tahun lepas, saiz sesuatu halaman web telah meningkat lebih kurang 25%, [...]
تيدوز » صفحات الإنترنت تصبح أكبر بنسبة 25% says:

November 27, 2011 at 6:21 am

[...] أن جافا سكربت أصبحت تستخدم بشكل أكبر من السنين الماضية.المصدر نستاهل؟ window.___gcfg={lang:'ar'};(function(){var [...]
25% الزيادة في حجم صفحات الانترنت في العامين الاخيرين - تتش أريبيا | تتش أريبيا says:

November 27, 2011 at 8:48 am

[...] (المصدر) [...]
Web page file size has become 25% in one year | Boagworld says:

November 28, 2011 at 12:51 pm

[...] is interesting about the report from Pingdom is that Javascript (44% growth) is the main culprit. However, increases in CSS (25%) and imagery [...]
Le pagine web diventano sempre più pesanti says:

November 29, 2011 at 8:27 am

[...] questo post per maggiori dettagli: Web pages are getting more bloated, and here’s why. Pubblicato in: Web Tag: tecnica, [...]
Latest Stats Say We’re Building a Fatter, Slower Web | Premium Shopping Store says:

November 29, 2011 at 3:04 pm

[...] friends over at Pingdom sliced and diced the HTTP Archive data and found that much of the remainder of the bloat can be [...]
Latest Stats Say We’re Building a Fatter, Slower Web - GRAFIC DESIGN – GRAFIC DESIGN says:

November 29, 2011 at 8:07 pm

[...] friends over during Pingdom sliced and diced a HTTP Archive information and found that many of a residue of a grow can be [...]
Se ingrasa si paginile web | Z0ltan77 says:

November 30, 2011 at 3:51 am

[...] Se ingrasa si paginile web Posted by Zoltán Márton on 30 November 2011 Marimea medie a unei pagini web a crescut de la 626 kB la 784 kB in decursul unei singuri ani conform celor de la royalpingdomon. [...]
SitePoint Podcast #140: Web Page Bloat | | says:

November 30, 2011 at 5:35 am

[...] Royal Pingdom: Web pages are getting more bloated. [...]
SitePoint Podcast #140: Web Page Bloat | ALL KNOWLEDGE FOUR YOU says:

November 30, 2011 at 7:40 am

[...] Royal Pingdom: Web pages are removing some-more bloated. [...]
SitePoint Podcast #140: Web Page Bloat | Reseller Web Hosting, Reseller Web Host says:

November 30, 2011 at 11:30 am

[...] Royal Pingdom: Web pages are getting more bloated. [...]
Latest Stats Say We’re Building a Fatter, Slower Web | t3knoDorKs says:

November 30, 2011 at 10:29 pm

[...] friends over during Pingdom sliced and diced a HTTP Archive information and found that many of a residue of a grow can be [...]
SitePoint Podcast #140: Web Page Bloat | PHP Podcasts says:

December 1, 2011 at 3:45 am

[...] Royal Pingdom: Web pages are getting more bloated. [...]
a . g r o o v e . i.knew.that.groove.was.in.your.heart says:

December 5, 2011 at 4:34 am

[...] Web pages are getting more bloated, and here’s why [...]
Bruce Lawson’s personal site : Reading List says:

December 5, 2011 at 5:30 am

[...] Web pages are getting more bloated, and here’s why. “Over the past year, web pages have on average become 25% bigger.” [...]
Ban the Bloat: 5 Reasons to Watch Your Page Weight | | says:

December 5, 2011 at 4:46 pm

[...] I’m stunned. I’ve written several web page <a href="http://www.sitepoint.com/page-weight-google-seo/”>bloat articles over the years but it’s all been in vain. According to Pingdom, a performance monitoring service, total web page file sizes have increased by 25% during the past 12 months. [...]
Ban the Bloat: 5 Reasons to Watch Your Page Weight | Reseller Web Hosting, Reseller Web Host says:

December 5, 2011 at 9:21 pm

[...] I’m stunned. I’ve written several web page bloat articles over the years but it’s all been in vain. According to Pingdom, a performance monitoring service, total web page file sizes have increased by 25% during the past 12 months. [...]
The mobile web in numbers | Royal Pingdom says:

December 7, 2011 at 11:20 am

[...] the mobile web regular web sites just won’t work. This could be because they’re too large (in terms of file size or pixel dimensions), they have scripting that is not supported by the [...]
The Paradox of Jevons’ Law, web page resource use, UX, and download times « Sustainable Virtual Design (Web/Virtual Worlds) says:

December 9, 2011 at 3:58 pm

[...] Here’s a link to “Web Pages are Getting More Bloated” – http://royal.pingdom.com/2011/11/21/web-pages-getting-bloated-here-is-why/ [...]
Latest Stats Say We’re Building a Fatter, Slower Web | LoQuor IT – Chicago Integrated IT Solutions says:

December 15, 2011 at 6:52 pm

[...] friends over at Pingdom sliced and diced the HTTP Archive data and found that much of the remainder of the bloat can be [...]
This Is Not The Net You Thought You Knew | TechCrunch says:

December 17, 2011 at 2:11 pm

[...] be so sure. For one thing, “vanilla” HTML is a smaller and smaller part of the average web page. For another, it’s increasingly HTML5, whatever that [...]
This Is Not The Net You Thought You Knew « Powerful Web Hosting says:

December 18, 2011 at 7:41 am

[...] right? Don’t be so sure. For one thing, “vanilla” HTML is a smaller and smaller part of the average web page. For another, it’s increasingly HTML5, whatever that [...]
Hold those caps: The average web page is now almost 1MB — Tech News and Analysis says:

December 21, 2011 at 4:31 pm

[...] The HTTP Archive charted the growth of the average web page and found that average web pages have grown from 726 KB a year ago to 965 KB now. The 33 percent jump is due in large part to more images and third-party scripts like ads and analytics. Javascript content, spurred on by the rise of HTML5, has grown over the last year by 44.7 percent, according to analysis by Royal Pingdom. [...]