Fast is the New Black

Express Email Marketing is one of the longest running products that Go Daddy offers. When I started at Go Daddy, almost 7 years ago, it was already a mature application. Over the years, the development team added a great many features, making it a compelling product. Unfortunately, we haven’t paid as much attention as we should to one of the most important features of all: performance.

In today’s Web environment, there are dozens of competitors for any type of application. If your application isn’t snappy or makes getting things done take longer than your customer would like, there is bound to be another product that will make him or her happier. We developers can no longer rest on our laurels or deliver more features and hope that customers will overlook slowness.

In this series, I will chronicle our team’s efforts to treat performance as a feature. I hope you pick up some tips from our experiences or, at least, that you might get motivated to give performance improvement the attention it deserves.

Steve Souders recently shared the Performance Golden Rule: “80-90% of the end-user response time is spent on the front end. Start there.” My interpretation of this statement is that the time spent generating the HTML on the server is dwarfed by transmitting that HTML across the Internet and then requesting all of the images, JavaScript, and CSS that are required to render it by the browser. The low-hanging fruit in this scenario is minimizing the number of requests, making them operate in parallel, and reducing latency.

Our 4.5 release of Express Email Marketing aimed at precisely that. Here is a waterfall chart obtained through WebPageTest.org pulled from their Los Angeles, California node for the 4.4 version:

The first thing that jumps out at you is how long the chart is. For the first page in our application, the Account Overview, there are an awful lot of requests. The next thing you see is the stagger, or staircase, of the slope. This indicates that a lot of the requests aren’t happening in parallel; they’re waiting on previous requests to complete before starting on the next set.

To put it in stark numbers, here’s the performance of that page on the first request and then on subsequent requests:

This was with GZIP compression of static resources, minification of JavaScript and CSS, and concatenation of scripts. We put in a lot of hard work in these areas last year, and it proved to be the easiest of easy wins.

For the 4.5 release, we looked at the next set of standard practices. We moved all of the static content to our CDN and replaced the complicated set of images that made up our left navigation bar with a straightforward jQuery accordion control.

Here’s the resulting waterfall chart—also via WebPageTest.org from their Los Angeles, California node—which you can tell immediately is a lot shorter due to the reduced requests:

And here are the revised numbers:

The biggest gain was clearly from the reduced number of requests obtained by changing the left navigation bar. This is an implication of the “Performance Golden Rule.” The best client-side request is one that the browser never makes. If you have 500 requests all being served from a CDN, it’s going to take a long time to load.

But, the effects of the move to a CDN are still impressive! We gain cookie-less resources, reduced latency from geolocated proximity, and aggressive caching directives. By staggering the JavaScript and style sheets on different subdomains, we get image and client requests downloading in parallel. None of these are trifling matters and get progressively more important the further away you are from our Arizona data center.

As I indicated before, this is just the beginning. With every release, we plan to incorporate performance improvements and make tweaks to keep bringing our numbers down. It’s just too important a feature to ignore.