By Craig Buckler

Ban the Bloat: 5 Reasons to Watch Your Page Weight

By Craig Buckler

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 average web page now weighs 784KB compared to 626KB in November 2010. Remember that’s an average: 50% of sites will exceed that size. To put it into context, a single page can be 10% of the browser application which was downloaded to render it.

The Pingdom article concludes that the main culprits are:

  • JavaScript: an increase of 44.7% (103KB to 149KB)
  • images: an increase of 21.2% (372KB to 451KB)

But why? HTML5 technologies are far more common. I would have expected a minor increase in HTML and CSS code — especially to cater for CSS3 vendor-prefixes — but shouldn’t JavaScript and image sizes should be dropping? There’s less need for image-generated gradients, coded animations, rounded corners, shadows, etc.

I also expected Flash usage to drop but it’s increased from 77KB to 87KB (13%). I suspect it’s primarily used in advertising, but HTML5 alternatives and Adobe abandoning mobile platforms are yet to have an effect.

So, is the problem that designers and developers rarely worry about page bloat? Anyone moving into the industry within the past five years has enjoyed the luxury of reliable broadband. Those who experienced the pain of dial-up connections often needed to optimize every byte — I can remember omitting closing tags and attribute quotes just to squeeze pages further.

Obviously the situation has progressed and few people would limit themselves to the 50KB maximum developers adhered to during the late 1990s. But there are many good reasons why you should habitually minimize your file sizes…

1. Search Engine Optimization
If two sites have similar content and page-ranks, the one which loads faster will gain a higher position in Google.

2. Reduced Cost
Smaller file sizes result in reduced hosting costs, bandwidth charges and user time. These factors are never free and, the more popular your site becomes, the more you’ll be charged.

3. Slow Connectivity
Just because you have fast unlimited access, don’t assume everyone else is sitting on a fat pipe. The situation is especially dire in the western countries which are dependent on aging copper telephone networks. A proportion your market will have a slow connection — or even dial-up — because that’s the best they can get.

4. Mobile Access is Increasing
Web access from smartphones tablets are popular. Eventually, they’re expected to overtake desktop browsing. Even those with reasonable 3G access will be waiting 30 seconds for your 1MB monolithic page to appear. Is that progress?

5. Developing Markets
Unlike the West, Asia and Africa will experience explosive internet growth during the next decade. The relative area sizes and population distributions mean that slow or mobile connectivity are the only option for the foreseeable future.

Perhaps those markets aren’t important to you now, but they will be. Besides, unlike the west, many of those economies aren’t bankrupt … they may become your only market!

Finally, let’s not forget that smaller file sizes normally results in more responsive applications. That’s good for everyone.

Let’s hope Pingdom’s 2012 report shows a big reduction in file sizes.

  • DH

    I enjoyed the article and you made many excellent points. I hadn’t heard point number 1 before though, could you provide a source?

    Also you said: “Remember that’s an average: 50% of sites will exceed that size”. Since Pingdom didn’t specify if their average was a mean or median value (I expect it was mean) it’s better to say “Remember that’s an average: many sites exceeded that size”, which is doubtless true in either case.

    Thanks for the article.

  • Hi Craig, thanks for the wake up call. While I always try to minimize load times and file sizes, it’s not frequent enough that I perform a page size analysis or examination on the final product. Javascript, too, man, I feel your pain. I see countless framework-driven sites (WordPress, Drupal, Joomla, …) that are so loaded down with Javascript (including JQuery) it just makes me shake my head. If you ask me the culprit in these cases are plugins and modules coupled with lazy point-n-click web developers or the do-it-yourself midnight warrior. For those of us who still hand code, take pride in our work, run our own servers and use CDNs — well, I like to think we’re helping the overall cause and piloting this bloated ship we call the Internet.

  • J. Stanley

    The amount of third-party javascript HTTP requests on some mainstream sites is ridiculous.

    Using NoScript, the amount of temporary allows I need just to view site content is getting out of hand. There doesn’t seem to be any rhyme or reason to the design of these sites, and the separation of content/layout/action is being trashed.

    Javascript is definitely being used on way too many sites to deliver content. Even Sitepoint links to no less than a dozen javascript domain servers to deliver this page.

    Unlimited broadband isn’t as ubiquitous as some content providers may think. Even the HTML5 VIDEO and AUDIO tags are a burden to some users. I always block them until needed.


  • I picked up on the “50% over the average” too.

    I think a lot of this comes about through a combination of laziness, more powerful browsers and proliferating broadband.

    jQuery is somewhere around the 90kB mark uncompressed. Not too many versions ago it was around the 70kb mark. Not too bad in a lot of cases, but there would be so many sites using jQuery for some minimal DOM/Event handling that need about 1/10th of the library. It’s such a defacto though that many developers wouldn’t consider another library, or JS without a library. Add on custom UI widgets and the layers of JS add up. I’ve even heard of sites loading multiple versions of jQuery accidentally.

    As broadband gets more widespread it informs the designs that people want to create. Big images, more of them, 24 bit PNGs, libraries, custom fonts etc. It can make for fun care-free development but those without the connections get left behind.

  • arti

    Some more things to add to point 4. Its not always the load time. I think a lot of people have only limited download amount on mobile each month (including myself -> 100 MB each mount, anymore, and I pay for every kB). So one site might load in a few seconds, but it could took you 0.5MB for each load. In such cases, use of cache should be a lot more encouraged.

    One thing that I have already tested is including all the javasript in one file. Most of the time I see a lot of pages that have one big jQuery file and many small (few lines files) that still demand connection to the server and consume time that way. So for example, if possible, include all javascript in one file (jQuery + all the animation effects etc. that you have on your site).

    I havent tested yet if this works with multiple frameworks (for example, jQuery and mootools in one file). Also, one thing to notice is that browsers now can download more JS files simultaneously -> this means that you could for example split jquery in 2 files and the download time would be cut down by half (but this would only pay off, it the download time is very big –> 2 HTTP connections generate some more server connections). Plus, I’m not sure if splitting a framework into 2 files wouldn’t break the framework. But in theory, it shouldn’t.

    • While a browser may download two JS files simultaneously, it can only execute each one as they appear on the page. As an extreme example, the first script could remove the second tag so the download is wasted.

      However, why would you need two frameworks? There’s a lot of functionality overlap.

      • arti

        Oh, ok, thanks for info – I havent yet went deep into how browsers handle JS.

        Well, I just made an example, I know that 2 frameworks are too much, but I’m sure that some people still include more frameworks on single page.

  • Anonymous

    Hi Craig,
    I don’t understand why your post exceeds 800K.

    • I’m not responsible for SitePoint’s template but the actual files served from servers is around 130KB. The remainder is advertising and social widgets which is slightly scary.

      • That’s also a large addition to other sites. Advertising and Social widgets are extremely important from a business standpoint.Good luck getting people to take those off their sites for the sake of a smaller file size footprint.

  • Sam Parmenter

    I think that you are massively over simplifying things here and missing one of the main reasons for these issues.

    People want the best website for the lowest cost and they are generating a lot of the content themselves.

    Jquery has ballooned over the last few years and everything seems to be built on top of it so even if you are using a small javascript plugin you will need to include the full jquery library.

    When the user is adding images to a website you are trusting them to do some rudimentary things like compress their images which a lot don’t do. It feels like you guys at sitepoint don’t have the experience developing websites that the average web dev does.

    Clients wan’t everything for nothing and have seen somewhere that does x, y, z that they want and they couldn’t care less that it will slow their site down. That is, until it slows their website down and they start whinging. I would love to work on a website where I could optimise the crap out of it but if I did that for most of my clients, I would be broke.

    • Most CMSs will compress large images for the web. They won’t do it as well as you can, but they’ll do a reasonable job.

      I don’t think jQuery is to blame, either. If you don’t need much functionality, don’t use jQuery. If you need a lot, jQuery is a great base to work from. Besides, many features such as animation can now be achieved with a few lines of CSS rather than JavaScript code.

      If your clients don’t understand bandwidth issues, it’s easy to educate them. Ask whether they want a responsive site which works well on mobile devices and saves them money? That’ll also save you time and increase profitability.

  • Rhett

    In my experience I have found that in a corporate environment there is not always time to prioritize for minimizing page weight. Designing something and getting it to work on a very quick turnaround not only feels rewarding and gets the marketing department excited — it’s a job requirement. However, my work at keeping things down is something I’m proud of, and it only becomes tangible to others when they start getting negative feedback from outside.

    Now managing the problem is probably something we could use some advice on. Generally the marketing department wants things rolled out quickly, and the material they hand off from the PR firms is weighty, they want specific analytics code snippets included, which is usually different to what you normally use, and so on. And then at the end of the campaign season when pages get taken down, the templates are still linked to a whole lot of extra resources, the css and javascript files are bloated, and no-one knows why or what to remove in case something breaks — a frequent problem with large websites that take a lot more time to check thoroughly. All because, quite frankly, very little attention is paid to the tear down process. Eventually the only way to press the reset button is a site redesign!

    You can add to the list of transgressors the growing use of non-traditional web fonts via services like TypeKit. When we develop our sites our font selection process takes into account the relative file sizes of the fonts we’re considering as well as the number of variants we include our kits. We take a similar approach with our use of JavaScript libraries: we chose jQuery only after assessing how it would save on bandwidth and what plugins give us the most mileage for the bandwidth they consume. Do other developers follow the same principles, or do they just jump into coding the first thing that works?

    In light of what I’ve mentioned already, there is one more reason we could add to this list: Whatever you code now is foundational for the next thing you’ll add to the site. A web site is never finished, so if you think you’re done you may setting yourself up for hours of tedious work later when the next round of changes and additions comes along.

    Though I am a designer, I’m also a developer and for that reason I’m not in the marketing department – which is good, because then I get to use my understanding of both worlds to keep marketing’s wishlist in perspective. However, from a developer’s standpoint I can admit there are also things we do that contribute to this waste of bandwidth, like building sites on an internal network! Even testing on iPads and iPhones gets circumvented by this, because to get around the firewall and save on costs, we browse and test our sites through the Wifi connection – kinda defeats the purpose.

  • Don’t count on anything shrinking. Obviously JavaScript is going to keep growing as people come up with more things for JavaScript to do. Flash and images are growing because people are starting to see that users love visuals and HTML5 video just isn’t enough yet. CSS3 still has too many people using old browsers for people to rely on it for the nicer effects.
    We also have to wonder how many developers actually pay attention to new things. I just see the marketing people demanding things that add page bloat and developers caring more about getting a product out than halving the file size of the site.

Get the latest in Front-end, once a week, for free.