2Mb Web Pages: Who’s to Blame?
I was hoping it was a blip. I was hoping 2015 would be the year of performance. I was wrong. Average web page weight has soared 7.5% in five months to exceed 2Mb. That’s three 3.5 inch double-density floppy disks-worth of data (ask your grandparents!).
According to the May 15, 2015 HTTP Archive Report, the statistics gathered from almost half a million web pages are:
| technology | end 2014 | May 2015 | increase |
|---|---|---|---|
| HTML | 59Kb | 56Kb | -5% |
| CSS | 57Kb | 63Kb | +11% |
| JavaScript | 295Kb | 329Kb | +12% |
| Images | 1,243Kb | 1,310Kb | +5% |
| Flash | 76Kb | 90Kb | +18% |
| Other | 223Kb | 251Kb | +13% |
| Total | 1,953Kb | 2,099Kb | +7.5% |
The biggest rises are for CSS, JavaScript, other files (mostly fonts) and—surprisingly—Flash. The average number of requests per page:
- 100 files in total (up from 95)
- 7 style sheet files (up from 6)
- 20 JavaScript files (up from 18)
- 3 font files (up from 2)
Images remain the biggest issue, accounting for 56 requests and 62% of the total page weight.
Finally, remember these figures are averages. Many sites will have a considerably larger weight.
We’re Killing the Web!
A little melodramatic, but does anyone consider 2Mb acceptable? These are public-facing sites—not action games or heavy-duty apps. Some may use a client-side framework which makes a ‘single’ page look larger, but those sites should be in the minority.
The situation is worse for the third of users on mobile devices. Ironically, a 2Mb responsive site can never be considered responsive on a slower device with a limited—and possibly expensive—mobile connection.
I’ve blamed developers in the past, and there are few technical excuses for not reducing page weight. Today, I’m turning my attention to clients: they’re making the web too complex.
Many clients are wannabe software designers and view developers as the implementers of their vision. They have a ground-breaking idea which will make millions—once all 1,001 of their “essential” features have been coded. It doesn’t matter how big the project is, the client always want more. They:
- mistakenly think more functionality attracts more customers
- think they’re getting better value for money from their developer, and
- don’t know any better.
Feature-based strategies such as “release early, release often” are misunderstood or rejected outright.
The result? 2Mb pages filled with irrelevant cruft, numerous adverts, obtrusive social media widgets, shoddy native interface implementations and pop-ups which are impossible to close on smaller screens.
But we give in to client demands.
Even if you don’t, the majority of developers do—and it hurts everyone.
We continue to prioritize features over performance. Adding stuff is easy and it makes clients happy. But users hate the web experience; they long for native mobile apps and Facebook Instant Articles. What’s more, developers know it’s wrong: Web vs Native: Let’s Concede Defeat.
The Apple vs Microsoft Proposition
It’s difficult to argue against a client who’s offering to pay for another set of frivolous features. Clients focus more on their own needs rather than those of their users. More adverts on the page will raise more revenue. Showing intrusive pop-ups leads to more sign-ups. Presenting twenty products is better than ten. These tricks work to a certain point, but users abandon the site once you step over the line of acceptability. What do clients instinctively do when revenues fall? They add more stuff.
Creating a slicker user experience with improved performance is always lower down the priority list. Perhaps you can bring it to the fore by discussing the following two UX approach examples …
Historically, Microsoft designs software by committee. Numerous people offer numerous opinions about numerous features. The positives: Microsoft software offers every conceivable feature and is extremely configurable. The negatives: people use a fraction of that power and it can become overly complex—for example, the seventeen shut-down options in Vista, or the incomprehensible Internet options dialog.
Apple’s approach is more of a dictatorship with relatively few decision makers. Interfaces are streamlined and minimalist, with only those features deemed absolutely necessary. The positives: Apple software can be simple and elegant. The negatives: best of luck persuading Apple to add a particular feature you want.
Neither approach is necessarily wrong, but which company has been more successful in recent years? The majority of users want an easy experience: apps should work for them—not the other way around. Simplicity wins.
Ask your client which company they would prefer to be. Then suggest their project could be improved by concentrating on the important user needs, cutting rarely-used features and prioritizing performance.
2015 Can be the Year of Performance
The web is amazing. Applications are cross-platform, work anywhere in the world, require no installation, automatically back-up data and permit instant collaboration. Yet the payload for these pages has become larger and more cumbersome than native application installers they were meant to replace. 2Mb web pages veer beyond the line of acceptability.
If we don’t do something, the obesity crisis will continue unabated. Striving for simplicity isn’t easy: reducing weight is always harder than putting it on. Endure a little pain now and you’ll have a healthier future:
- use tools to encourage caching, reduce HTTP requests, minify payloads and remove unnecessary components—see The Complete Guide to Reducing Page Weight
- consider Chris Ruppel’s idea of Throttled Thursdays to limit your bandwidth and experience your site/app like your users.
It’s time to prioritize performance.
