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

Problem loading page

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. Need to know how fast your site is? Use our page speed tester to find out. 

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.


  1. 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.

  2. 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).

  3. 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.

  4. 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

  5. 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!

  6. @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?

    1. @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

  7. 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

  8. 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”.

  9. 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…

  10. 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.

  11. 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.

  12. 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.

  13. 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.

  14. 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.

  15. 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.

  16. 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/)

  17. 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 ?


    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.


    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?

  18. Extremely informative article . Thanks a lot for providing answers to
    the questions i was pondering on for a long time so simply & effectively !!!

  19. Extremely informative article . Thanks a lot for providing answers to
    the questions i was pondering on for a long time so simply & effectively !!!

Leave a Reply

Comments are moderated and not published in real time. All comments that are not related to the post will be removed.