As I look back at the state of 2011 web operations, the thing that impressed me the most was the success of the Web Performance Optimization (WPO) movement. Comparing it to recent world events, I think this movement is the “Arab Spring” of the Web Development and Operations community. Web Performance meetups launched everywhere around the world, Velocity Conference got a passport and travelled to Europe and China, the number of people interested and invested in this subject have exploded, and so have the number of companies and investments in this field.
The success of this movement is mostly due to the hard work of several individuals and companies in the last 5 years Steve Souder, Patrick Meenan, O’Reilly, Google Speed initiatives, Joshua Bixby, Sergey Chernyshev, Stoyan Stefanov, Alexander Podelko, and so many others. Thanks to them WPO and Web Performance Monitoring is no longer reserved to the few 1% who can afford fast servers and bright engineers. The techniques to speed web sites have been documented (Yslow, Google Pagespeed), books have been published (High Performance Web Sites: Essential Knowledge for Front-End Engineers by Steve Souders, Web Performance Tuning: Speeding Up the Web, Building Scalable Web Sites: Building, Scaling, and Optimizing the Next Generation of Web Applications, Even Faster Web Sites: Performance Best Practices for Web Developers), and automated optimization tools have flourished like aiCache, Strangeloops, Blaze.io, etc.
This movement has been amazing as it makes the web experience for end users faster and better. Another positive development has been also sharing that is taking place in this industry thanks to sites like PerfPlanet, twitter and engineerings teams are quick to share their latest experiments and results like Wayfair, Netflix and Etsy.
But as 2011 is winding down I am still perplexed by the lack of implementation of 2 major WPO best practices that give the most performance boost without any development efforts or new hardware: HTTP Compression and Persistent HTTP Connections.
I am not sure if this is by choice or negligence or a combination of the two. In regards to compression, when there is a CDN involved I think it’s mostly negligence because CDNs do not automatically turn on compression. I have been on way too many calls where I have heard “oh we forgot to turn that on”. Please compress HTTP on your own servers and ensure your CDN has compression enabled for your account.
While we monitored the top 50 retailers on Cyber Monday, the Sony.com homepage downloaded around 2.6 mb of data, of which 1.2 mb where un-compressed CSS and JS! In this case their CDN is Akamai. ([See link to HTTP ARCHIVE 11/15/2011](http://httparchive.org/viewsite.php?u=http%3A%2F%2Fwww.sonystyle.com%2F&l=Nov 15 2011)). The compression at the CDN level must be ON by default and not the other way around.
“Persistent Connection” or “Keep Alive” is a feature of HTTP 1.1 which allows a browser to re-utilize an existing connection with the server. Today almost all web servers and browsers support HTTP 1.1 Keep Alive and there is no reason why so many sites still do not have it enabled. The biggest advantage is that it eliminated the need to establish an HTTP connection for every request to the server – which can quickly add up.
So on the 2nd of January 2012, please take the time to make a call, send an email, fax, or even send pigeons with these 2 instructions to your operations or devops and CDN account rep: Turn on Compressions for all HTML, scripts, css and text resources; and make sure Keep Alive is on!
You will save money on bandwidth, your end-user will be happier and your systems and network will be less bloated!
Mehdi – Catchpoint