Speed as a Feature, Part 1

By: Chris Kelly | Posted in: Performance Tech Tips, Performance Tuning, Top Post, Jul. 9th, 2012

This is the first of my posts on Speed as a Feature. It was inspired by a talk I recently gave to the CTO Forum in San Diego. As both a former CTO and emeritus member, I was humbled by the invitation and excited to find out what keeps some of the brightest technology leaders up at night. If you’re interested, you can jump directly to the slidedeck that accompanied the session.

When describing your application to users, peers, VCs or potential new hires, which features do you list? Do you talk about the latest social sharing integration? How about the API you built? Or maybe you can’t stop glowing over your Cloud-based real time local big data feed? But when was the last time you talked to someone about how fast your application is?

I’m sure this isn’t because you don’t care about performance. (You just haven’t had time to fix that memory leak yet.) But building performant web applications rarely happens by chance. At some point, you need to make performance a priority.

Unlike adding a tradition feature (such as photo uploading), adding performance to your feature list isn’t nearly as straightforward. Simply writing good code doesn’t guarantee your app will be fast. (Thought it certainly won’t hurt!) And you can’t just bolt performance on to your application by adding a new library or changing a flag in your configuration. Performance needs to built into your app from the start and become part of your development culture.

Performance Benefits Your Business
Still not convinced? I’ve got some cold hard metrics for you. According to a report by the Aberdeen group, a page that takes an additional second to load sees a 7% drop in conversions. That same second also costs you 11% fewer page views. Amazon is famous for their page load optimization and for good reason. For every 100ms delay that Amazon has in their load times, it sees a 1% decrease in its annual revenue. That’s $480M in 2011!

Performance Benefits Your Developers
As engineers, we want to work on interesting and hard problems. I’ve never met a developer yet that enjoyed firefighting more than creating something new. In our lean development cycles, we’re supposed to build, measure and learn. But that’s really hard to do when you are regularly going back to refactor code that’s dragging down your performance. With enough neglect, all your time is spent mired in fixing performance problems rather than writing that new feature.

You don’t call the plumber when your house is under water — you call them when you see a leak. Likewise, performance problems are something you need to anticipate or you should plan on keeping your goulashes handy. Make performance a feature of your application. If you aren’t monitoring apps already, you need to start. Put performance on your backlog and try turning it into a hack day.

The more work you put into performance, the more time you’ll have to work on the stuff that matters. An application built with a disposition towards performance will have a smaller footprint and utilize fewer resources. And the less resources you have to manage, the more time you can spend working on adding new features

In the next installment, we’ll take a look at what’s going on in the frontend of your application that might be causing a serious performance hit without you even knowing.