Over a million developers have joined DZone.

What I’ve learned From Monitoring Four Years of Web Page Bloat

Web pages can teach us a lot, especially with consistent monitoring. Check out this romp through the history of web page bloat over the past four years, and what it can teach us.

· Performance Zone

Discover 50 of the latest mobile performance statistics with the Ultimate Guide to Digital Experience Monitoring, brought to you in partnership with Catchpoint.

Every six months I take a look at a handful of key stats from the HTTP Archive — a fantastic repository of historical data around the size and composition of half a million of the most-visited websites in the world — and I benchmark them against the previous six months.

For the Archive’s recent four-year anniversary, I thought it would be interesting to take stock of the past four years — what’s changed, what’s stayed the same, and what I’ve learned as I’ve watched all these numbers creep upward.

The Average Web Page is 2219 KB Today, Compared to 991 KB Just Four Years Ago

The average page surpassed the 2 MB mark last spring, when it hit 2099 KB. Today, the average page is 16% heavier than it was one year ago, and 139% heavier than it was just four years ago.

Page bloat and web performance

In the past six months, the average page has added another 120 KB of girth. It’s tempting to dismiss this added weight. What’s another hundred or so kilobytes in the grand scheme of things, right? But it’s not so much the extra weight that we need to worry about. It’s what this weight represents: more page assets (e.g., images, CSS files, and various scripts), more page complexity, and more risk of performance malfunctions. More on all this further down in this post.

Images Make Up 64% of the Average Page’s Total Weight

This isn’t completely new information. For as long as I’ve been tracking the HTTP Archive, images have always comprised at least 60% of the average page’s total payload.

page bloat 2011 to 2015: images

What is rather incredible is how quickly this number has grown in a relatively short period of time: the total image payload has more than doubled in just four years. Even more incredible is the fact that, today, images alone account for more page weight than the average entire web page just over two years ago.

page bloat and web performance: images

But Size isn’t Everything

Last month, Nate Berkopec wrote a fantastic blog post, in which he breaks down why you’re making a mistake if you focus solely on page weight. This bit nails it:

The secret is that “page weight”, broadly defined as the simple total file size of a page and all of it’s sub-resources (images, CSS, JS, etc), isn’t the problem. Bandwidth is not the problem, and the performance of the web will not improve as broadband access becomes more widespread.

The problem is latency.

Most of our networking protocols require a lot of round-trips. Each of those round trips imposes a latency penalty. Latency is governed, at the end of the day, by the speed of light. Which means that latency isn’t going anywhere.

I’ve written in the past about why more bandwidth isn’t a magic bullet for fixing performance issues, but my post focused on the fact that many people don’t understand that double the bandwidth doesn’t equal twice as fast.

Nate’s post highlights a different issue: for as long as latency continues to be a performance problem (which is to say, pretty much forever), the major performance culprit will continue to be the fact that a typical web page today contains a hundred or so assets hosted on dozens of different servers. Many of these page assets are unoptimized, unmeasured, unmonitored — and therefore unpredictable.

As a for-instance, let’s look at the sudden rise of custom fonts. In just a few short years, they’ve gone from being barely used on just 7% of websites, to dominating more than half of all the websites tracked by the HTTP Archive.

page bloat and web performance: custom fonts

Custom fonts are a huge boon for designers. Allowing you total control of your brand’s visual assets isn’t trivial in a marketplace where branding has never been more important. But when your custom fonts are poorly implemented or hosted externally, this introduces the potential for performance pain — ranging from sluggish fonts that result in annoying FOUTs (flashes of unstyled text) to unresponsive fonts that completely block the rest of the page from loading (yes, I’ve seen it happen).

And custom fonts are just one type of asset. You also have stylesheets, JavaScript, and potentially dozens of rogue third-party tags. At best, these assets are incrementally increasing your total latency hit. At worst, they’re introducing potential single points of failure for your pages.

So…What Can You Do?

1. Set a Performance Budget for Your Pages

One thing that many fast pages have in common: most are around 1 MB (or less) in size. Not coincidentally, 1 MB is the size that many companies are establishing as the top end of the “performance budget” they set for their pages. This isn’t about making pages smaller just for the sake of making them smaller: it’s about forcing yourself to prioritize the assets that appear on your pages and do some strategic culling in order to make pages simpler and reduce latency. If you’re unfamiliar with the idea of a performance budget, Tim Kadlec has written some excellent posts that do a great job of spelling out why you need a performance budget and what kinds of metrics you should track.

2. Tackle Images First

If you want to score some quick performance wins, start with optimizing your images. Here’s a high-levelimage optimization checklist I created to get you started with introducing the importance of image optimization to everyone in your organization (particularly non-technical folks). For a deeper dive, I highly recommend Guy Podjarny’s post High Performance Images: Beautiful Shouldn’t Mean Slow.

3. Optimize Your Fonts

Ilya Grigorik has written an excellent post about webfont optimization, which is a must-read for designers and developers.

4. Get a Handle on Your Third-Party Scripts

A typical web page can contain 75+ third-party scripts, and when it comes to managing their performance, it’s still a Wild West situation. Many site owners have literally no idea how their third parties are performing in the wild and how this performance affects their pages. Here’s a short primer to help you get a handle on your third-party scripts.

5. Educate Everyone Who Touches Your Web Pages

There are so many people — from business owners to marketing folks — whose decisions affect how a page performs. All of these people need to be aware that every decision they make — from implementing a new third-party widget to using an animated gif as a hero image — has an impact.

6. Understand the Impact that Page Size and Complexity Has on Your Business

This is a corollary to understanding the impact that page size and complexity has on your load times. Once you’ve connected the dots between page size, complexity, speed, and business performance, it’ll be that much easier to know where to put your optimization energy. If you’re new to this area of study, I wrote thisshort history of web performance and its impact on business metrics. And if, like me, you’re a nut for case studies, Tim Kadlec and I also recently launched WPO Stats, a repository of studies that show the correlation between performance and business success.

Is your APM strategy broken? This ebook explores the latest in Gartner research to help you learn how to close the end-user experience gap in APM, brought to you in partnership with Catchpoint.

Topics:
performance ,monitoring ,web performance

Published at DZone with permission of Tammy Everts, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}