The HTTP Archive Report collates information from almost half a million of the web’s most popular websites. The latest figures indicate that average page weight has increased by 15% in one year to reach 1,953Kb — a little under 2Mb — and comprises 95 individual HTTP requests. While this is smaller than the 32% increase in 2013, it remains cause for concern.

The report analyzes publicly-accessible content and shopping web sites rather than complex web applications and provides a breakdown of the technologies used:

technology end 2013 end 2014 increase
HTML 57Kb 59Kb +4%
CSS 46Kb 57Kb +24%
JavaScript 276Kb 295Kb +7%
Images 1,030Kb 1,243Kb +21%
Flash 87Kb 76Kb -13%
Other 205Kb 223Kb +9%
Total 1,701Kb 1,953Kb +15%

These are average figures; a large proportion of pages will have greater file sizes.

A 2Kb rise for HTML seems reasonable although it’s a significant quantity of content given the trend for simpler, more concise text.

What surprises me most is CSS’s 11Kb rise. Responsive Web Design and CSS3 animations could account for some of this increase but there’s not been a drop in JavaScript. Despite the availability of CSS management and minification tools, the average site also makes six requests for CSS files.

JavaScript has risen by 19Kb. This is confusing; the need for shims is reducing, effects can be handed to CSS3 and monolithic libraries have fallen from favor. Sites make an average of 18 JavaScript file requests, which is unchanged from last year — although a quarter of sites make more than 30 requests. Perhaps some of the gain can be explained by increasingly sophisticated/bloated social networking scripts?

27% of sites continue to use Flash — a fall of 5% over the year. The majority is used for advertising, video, and games. Flash hasn’t dropped as fast as expected but its future is clear.

There’s been a 9% increase for “other” files. That figure doubled in 2013 but, back then, custom fonts and icon fonts were relatively new.

Finally, images are responsible for 85% of the weight gain. Using high-resolution (Retina) images could account for some of this hike, except:

  • Pages contain more than fifty images, which seems excessive.
  • Retina accounts for a relatively small proportion of devices.
  • SVG, icon fonts, and CSS3 effects can replace many images.
  • There are numerous tools to help reduce file sizes.

Additional Factors

The survey also reveals:

  • 95 HTTP requests are made per page — a drop of a single request from last year.
  • Pages contain 862 DOM elements.
  • Resources are loaded from sixteen domains with a maximum of 52 requests per domain.
  • The average PageSpeed score is 78 out of 100 — which is surprisingly good, given the bloat.
  • 46% of pages use Google libraries.
  • 47% of pages use custom fonts.
  • 79% of responses are compressed (gzip’d).
  • 14% of pages are loaded over HTTPS.
  • 20% of pages use localStorage.
  • 65% of pages use iframes (mostly videos and advertising).
  • 74% of pages use at least one redirect — which seems high.

The Primary Suspects

A 15% increase is less extravagant than the 32% rise in 2013 and the 30% rise in 2012, but it’s still too much. Has your bandwidth increased more than 15% in the past twelve months? A third of web users now use mobile devices — will they appreciate the additional weight?

Let’s put this into context for website owners. Bloated pages adversely affect your profitability:

  1. Users have a slower experience. It doesn’t matter how great your site looks — people will not wait.
  2. There’s little point creating a site that works on mobile devices when your pages are 2Mb. Responsive Web Design != a responsive website. Are you losing up to a third of potential customers?
  3. Google will downgrade your site and harm your search engine optimization efforts (though we’re never sure exactly how much this matters to Google’s algorithm).
  4. Your hosting costs will increase.
  5. The more code you use, the more likely it will break. Updates and maintenance are more difficult, take longer and cost more.

It’s ironic that web developers praise the benefits of cross-device HTML5 apps when a single page is often larger to download and slower than an equivalent native app.

Overweight pages are unnecessary. My primary suspects remain bloated CMS templates and frameworks. They offer a cheaper and quicker development route at the expense of quality, efficiency and performance. Many are packed with features you’ll never use, but removing them can be laborious, tedious, and time-consuming.

We can summarize the problem in one simple word: laziness. Developers are at fault — that’s you and me. We have plenty of excuses:

  • there’s never enough time
  • the client insisted it should be done this way
  • the budget/schedule is too tight
  • I inherited a shoddy system
  • I don’t have the tools

Whether it’s technical boundaries or a failure to explain issues, it’s still laziness. We work at the coal face; the final decisions are ours alone. Why create a badly-optimized site when many bloat-blasting solutions are simple and take minutes to implement?

Clients rarely appreciate the efficiency gains we make but they don’t understand anything we do. We are the experts, and minimizing page weight is an essential part of the job. Do it. It’s easier to beg for forgiveness than to ask for permission.

</rant></soapbox>

Are you concerned by the web obesity problem? Are you pleased the scale of increases has dropped? Do you or fellow developers struggle to implement optimization techniques or to explain them to clients? Do you think there are other causes? Is Craig being too simplistic and shouty?!

Tags: page-weight
Craig is a freelance UK web consultant who built his first page for IE2.0 in 1995. Since that time he's been advocating standards, accessibility, and best-practice HTML5 techniques. He's written more than 1,000 articles for SitePoint and you can find him @craigbuckler
Comments
isights

Seems obvious to me. The increase in image weight isn't so much retina as it is the fact that we're increasingly building more single-page layouts utilizing ever larger background and parallax images.

Further, the CSS size increase is (or should be) fairly obvious as well: we're building responsive layouts that contain more media queries and device specific breakpoints and layouts. Web sites now need the CSS to look good on the desktop, on tablets, and on mobile phones.

RyanReese

I'd also think it's because more and more people are using frameworks - all that added code. That was my original thought when this was posted. Media queries are probably mixed in there also.

zackw

I blame framework bloat and overuse of scaffolding as well.
I cringe whenever I look at the CSS source of something cool, only to see something as simple as a box with a title drowning in 300 lines of CSS, with the same color and other attributes overridden 3, 4, 5 times.

The typical workflow now is start with a framework, then another theme/style, then a master file, then an override file, etc etc. Don't touch the master, just customize in an override.

I almost wish we could go back to the old days where we, shock, just style the site directly as it's supposed to be, and not have to constantly override CSS that isn't used in the first place.

I believe a rise in simple, minimal CSS frameworks will come back, with technologies like SASS and SCSS allowing us to style sites and generate single-level CSS that doesn't not require overrides and bloat.
Either that or we'll see a resurgence of designers wanting to build all custom CSS again, and a slew of tools to allow quick style development.

chris22smith

That's all a bit depressing. I think the point about the laziness and dependency on ready-made, bloated solutions is absolutely spot on. At least now we all know what our resolutions should be for 2015!

StevenHu

Could full-stack development be part of the problem, with all those dependencies being added in?

mouhsine_bakhich

project schedule and budget do not allow me to optimize the website for fast laoding ,if i spend a month optimizeing one single project than i should complete in the street because i wont be able to pay my rent with what clients offer this days.

ceeb

Really? So you spend more time adding more code to meet schedules and budget? Fast loading pages use less code!

It's also self-defeating. If your system is slow, people won't use it. Your client's business is affected and they won't be able to hire you for future projects. There are times you need to be pragmatic, but no developer need purposely create a badly-performing system. At the very least, you can highlight the issues to your clients - it may lead to additional work.

mouhsine_bakhich

when i said i dont take time to optimize the website for fast loading ,i'm not talking about using sprites ,minifyng css javascript, caching the database queries ,because i do that in very project and i got used to it ,what i'm talking about is the extra work that i can do to optimize it even more , like minifyng images ,implementing ajax calls ,etc ..

ceeb

Minifying images will to lead to a far smaller payload than any amount of JS and CSS mangling.

But this isn't really about the mostly insignificant extra work. It's about changing attitudes...
http://www.sitepoint.com/complete-guide-reducing-page-weight/

Learn Coding Online
Learn Web Development

Start learning web development and design for free with SitePoint Premium!