Average Page Weight Increases 30% in 2012

Tweet

As we approach the end of 2012, I thought I’d consult the HTTP Archive Report which collates technology statistics from 300,000 of the web’s most popular sites. The staggering news: average page weight has bloated by 30% in one year to reach 1,250Kb. Yes, 1.25Mb.

Some of this obesity can be explained by the holiday and gift-giving season. If you examine the top 100 sites, page weights have expanded from 584Kb to 955Kb in two months — a massive 64% increase. The extra bulk is primarily images and Flash advertising. That may reduce once normality resumes and people become fed up with persistent panic shopping.

Breaking these figures down into specific technologies:

technology end 2011 end 2012 increase
HTML 42Kb 52Kb 24%
JavaScript 167Kb 214Kb 28%
CSS 32Kb 41Kb 28%
Flash 90Kb 90Kb 0%
Other 629Kb 852Kb 35%

The vast majority of these pages are publicly-accessible content websites rather than JavaScript-heavy applications or canvas-based games. ‘Other’ is mostly media such as images but will also include font stacks. Custom font usage has increased and is used by 13% of websites — up from 7% a year ago.

Flash has remained steady. The technology may be in decline but it remains the most viable option for cross-browser animated advertising. Besides, an average weight of 90Kb is a mere 7% of the total weight.

An increase in HTML code is likely as the industry moves toward HTML5. Simple semantic changes such as replacing a div with header or footer requires a few more bytes. Some functionality and validation can also be implemented in mark-up which was not previously possible.

A rise in CSS is also understandable. Modern CSS3 effects incur further properties and many require vendor-specific prefixes (that said, many developers don’t use all of them appropriately — see The Impending CSS Vendor Prefix Catastrophe).

However, the combined HTML5 and CSS increase should be offset by a far greater decrease in image file sizes. Fewer images should be required given that rounded corners, shadows, gradients and translations permit effects where graphics were previously required.

Similarly, many JavaScript-powered effects are unnecessary and less sophisticated than equivalent CSS3 transitions and animations. Admittedly we are in a transitionary period: most JavaScript libraries still provide animation functions for IE9 and below. But that doesn’t explain the 28% jump in file sizes.

I suspect two primary reasons for the page bloat. A fashion for large, high-quality, full-screen textures and photographs. This can only be ‘fixed’ by educating designers and clients. The second reason is more endemic: developer laziness. Do you or or colleagues…

  • rely on one-size-fits-all frameworks and never remove redundant code?
  • use multiple libraries or cut-and-paste coding to achieve different effects?
  • not concern yourself with the consequences of page weight?

The first consequence is SEO. The overall impact may be relatively minor, but Google factors page speed into its ranking algorithms. Those who don’t care about SEO shouldn’t consider themselves professional web developers.

The next issue is user experience. Bandwidth is rarely plentiful and it’s never free; bloated pages result in slower downloads, execution and response times. This is especially evident on mobile devices — you probably have a blacklist of sites to avoid on your smart phone. Does it include your own site?

Finally, let’s not forget that 1.25Mb pages is an average. Assuming a normal distribution, half of those surveyed will be larger. That’s ridiculous for content websites and, ultimately, it will cost them visitors.

Should your site go on a diet? Why has it gained weight? Are you planning to resolve the problem?

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • http://CertainWebDesign TCertain

    The reason Flash is steady? Have you taken into consideration the fact that any android device now has no ability to run flash anymore? With the last 2 android updates, Adobe has so kindly decided that we no longer need Flash. So any site that has it, I don’t get to see it. So I guess web developers have decided, I know I have, that there is no place for flash in any of my sites.

    • http://www.optimalworks.net/ Craig Buckler

      Adobe has abandoned mobile (well, they were forced to given that Flash was banned from iOS). But on the desktop, it remains a viable method of delivering adverts to most browsers.

  • David

    Tackling the page weight issue is a constant struggle at our ecommerce company. Certainly images and promotional banners, etc account for a big chunk – which we can address easily enough with caching for repeat visitors. A bigger issue for us is the bloat in javascript : review data, analytics, remarketing, event tracking and live chat code.

    Despite our best efforts, it’s near impossible to get our pages below 500kb nowadays.

    @TCertain – that site needs a lot of work.

  • Stevie D

    One of the biggest bugbears I have at the moment are pages that have a photo carousel. So not only have you got the bloat of jQuery to worry about, you’ve then got several large photos to download, usually at high quality, which is a major headache when you’re on a slow connection or a slow computer.

  • Adam Fasoldt

    I’m not sure that an average of 1.25mb is really a big deal given that, most of the time, that’s a one time thing. After that, with browser cache, you’re looking at 60kb-200kb per page.

    • http://www.optimalworks.net/ Craig Buckler

      Yes, but take a look at your browser stats. The majority of users look at one or two pages (unless you happen to be Facebook). Even then, caching is not an excuse for optimization.

  • http://www.we-are-a-knockout.co.uk Dave Knockout Games

    WordPress and bloatware CMS / Blogs do not help?? When a web developer builds a site properly he / she controls page weight by only linking / attaching what is needed. Many CMS are all or nothing – usually ALL and they handle image compression poorly. Of course the Jo Bloggs user uploads his 16 Megapixel images for his off-the-shelf template for “my holiday”.

    I guess the web has become more media based and image conscious… and corporates duplicate content over all the channels too. I was an advocate of accessible web design but gave up when iPhone et al came in – it just got too hard to slim down and test everything and site owners demanding more bandwidth hugging bellls and whistles with no care for speed.

    Broadband has led to the rich media we all like but is also means that many care less about trimming sites down… So yes websites are now bingeing on bandwidth like they just discovered a virtual fast food joint on the information highway (very old phrase LOL )

    • http://www.optimalworks.net/ Craig Buckler

      Mmm, I agree that CMSs have some bloated let’s-handle-every-possibility themes, but you don’t need to use them. I nearly always use custom hand-built themes for that reason.

  • http://chr.ishenry.com/ Chris Henry

    I’m sure accusing web developers of being lazy is a great way to get this problem fixed, which is also endemic among idiots who have no idea what they’re talking about.

    Web development is a collaborative effort, and most devs I know always put performance and speed up at the top. It’s extremely easy for folks to look at the massively fat pipes and deep pockets of the likes of Facebook and Bing, who have done a fantastic job of making delivery of the hi-res, shiny features look extremely easy. But for the average web dev shop with limited time and resources, the best way to get the best product out to the customer is to use multiple libraries. Often times, designers and business parties become extremely uninterested in bandwidth costs when estimates for time and cost rise. I would say the major issue here is technical education to the tune of bandwidth usage.