Webpage bloat accelerates

Yes, that outfit makes your backside look broad.

New networking technologies, energy-saving processors, gestural inputs, highly-parallelized algorithms–there’s an abundance of exciting innovations in information technology (IT) to consider. At the point where real end-users view applications on practical screens, though, much of what happens is thoroughly mundane. Radware solution evangelist Tammy Everts expertly details how much of today’s Web experience is a result of the simple gross inflation of Web payloads–over 50% in just the last twelve months!

IT Ops” has covered reports from Radware before, and bloat more generally. Everts in particular writes quite clearly on her own behalf, though, and all of her piece, just published this week under the title, “The average web page has almost doubled in size since 2010”, is worth your study. I’ll emphasize just a few points from it:

  • As always with Radware, analysis has a basis in careful measurement. While I haven’t reviewed artifacts from HTTP Archive myself, its methodology sounds appropriate and sensible. “[D]ouble in size” is not a casual encoding of an emotional reaction; it means, precisely, growth from 828 kilobytes per average subject page, to 1246 kilobytes.
  • It’s not Flash’s fault, and certainly not CSS3’s or that of clumsy publish-to-HTML content managers. Nearly all of the growth is from images, video, and, somewhere behind those, JavaScript libraries.
  • Everts lays out facts that have shown up in “IT Ops” and elsewhere repeatedly: nearly all images now bloating real-world Web pages can be quickly optimized in several mechanical ways, including choice of a more appropriate format, reliance on compression, and use of progressive image rendering (PIR).
  • It’s not just that the majority of Web pages can easily be re-coded to demand substantially less bandwidth; the discouraging but documented reality is that use of “best practices” has retreated in recent years.

Moral exhortations to code to higher standards are … well, none of us should hold our breath waiting on that “solution”. One of the attractions of application performance management (APM) is that it does more than help locate, diagnose, and solve incidents of poor responsiveness. It also provides quantifications for long-term comparison, and, perhaps most of all, helps focus on the performance problems that are worth fixing. One of the lessons of reports like Everts’ is that we don’t lack for knowledge about how to improve Web pages; most of the time, though, the coders experienced enough to put that knowledge into practice are already busy with other responsibilities. APM nearly uniquely shows where their precious attention is best directed.

Don’t count on a cheap technical fix to get us out of this one, moreover. Recent public statements from executives at both Comcast and Time/Warner make clear that the cable providers are in no hurry to provide fatter pipes. It’s up to us to make better use of the networking already available to us.