Fast by default
A couple of weeks ago I had the opportunity to go to the 2010 Velocity Web Performance and Operations Conference in Santa Clara, California. Velocity was partly set up by the godfather of web performance, Steve Souders (then at Yahoo, now at Google) 3 years ago as a way to openly discuss and push web performance and web operations techniques to the ever expanding audience of software developers and engineers demanding this knowledge in the age of massively scalable web sites. Velocity has been high on my conference bucket list – with over 1000 attendees and close to a hundred speakers it’s a who’s who of web performance.
Anyone that’s followed me or this blog for a while knows that performance is a favorite topic of mine, one I’ve presented on a few times including at TechEd last year. The theme at this year’s conference was “fast by default”: I’ve always thought performance is the number one non-functional requirement for all software and Velocity is about making web software much much faster.
First the bad news: there are still web developers out there that still don’t understand basic web performance! If you don’t know the 14 rules then learn them! Having said that we at Xero often let ourselves slip into bad practices – it’s very easy to get complacent with performance, but everyone in your organization should be thinking about it – not just the performance team (if you even have one) – everyone from development to operations to QA to marketing needs to understand the impact that performance can have – it needs to be baked into the culture. This often means aligning performance metrics with real-world business metrics – if I speed up my website by 1 sec will that increase conversions? Or to put it more simply: will 1 second make me more money? This is stuff that is core at the big players such as Google & Yahoo & Facebook – but it’s relevant to any size organization trying to make it’s way on the web.
Fortunately most of the talks were at a deeper level – getting to the nitty gritty of performance. There were a few talks that tackled the subject of the inner workings of the web: John Rauser from Amazon was brilliant in tackling the usually dry subject of TCP and the problems inherent in a protocol that was invented almost 20 years before Google was, and Tom Hughes-Croucher from Yahoo! provided a detailed look at what happens in the lifetime of a single web request. There are still developers out there that don’t really understand what happens during an HTTP request and how much inherent latency there is in the Internet. We’re all at the mercy of the laws of physics (unfortunately New Zealand, the speed of light is a contributing factor when connecting to web sites hosted in the US) but there is still a lot that can be done to improve the bits between your computer and the web server. Probably the most interesting discovery was how simple things such as the quality of a user’s router can have such an adverse affect on web performance. In fact there’s a big push at the moment to get Internet Service Providers to worry less about increasing bandwidth, but rather focusing on providing better quality gear to their customers (it doesn’t matter if you have 1 Gbps to your home if your router can barely handle 5 Mbps). It’s also interesting to note the work that Google has been doing with protocols like Spdy to try to improve the bits of TCP that weren’t designed to cope with the size of the current Internet. Again – latency is the killer – Google have proven that improving latency has a much greater benefit on the speed of websites than adding raw bandwidth.
Overall Velocity lived up to the hype and has definitely made me think about the thing we could do better at Xero. While we’ve done some good work there is still so much we could do to make Xero fast by default – which can only be a good thing for our customers.