March 2013 Site Performance Report

Posted by on April 9, 2013

Four more months have gone by since our last update, and it’s time for another performance report!  We made it through the holiday season with flying colors, and our engineers have been hard at work launching new features since the new year started.  Let’s see what impact this had on performance (spoiler: we keep getting faster).

Server Side Performance:

Here are the median and 95th percentile load times for signed in users on our core pages on Thursday, 3/14/13:

Server Side Performance Chart

As you can see we had small decreases in load time across the board (the one exception being a tiny uptick in median search performance).  We expected this, since we made a couple of small changes to our application code in the last couple of months that had a positive impact across every page.  The larger decrease in the 95th percentile load time for the homepage was primarily due to the removal of the Taste Test module.

As a quick reminder, the “Baseline” page is an extremely simple page that just includes our header and footer, and uses our normal controller architecture.  Improvements in the load time of this page mean improvements across every page on Etsy.

We also thought it would be fun to look back and compare our performance today to our performance from the very first performance report, back in August of 2011.  Since we don’t look at averages anymore, we can only compare the 95th percentile:

Performance comparison 1.5 years

Looking good!  We have made huge strides on the homepage, shop page, and profile page, and a small improvement on the search page.  The listing page hasn’t seen much optimization given its position as the fastest of these pages, so we’re happy with its modest gains.  It’s extremely gratifying to see how much progress we have made over the last ~18 months, and we hope to continue this trend in the months to come.

Front-end Performance:

We changed our strategy for monitoring front-end performance in our last update, and promised more stable metrics going forward.  That proved to be the case:

Frontend Performance - March 2013

Performance looks good here as well – reductions in load time for almost every page type again.  The one outlier here is our baseline page, which saw a significant increase in document complete time since our last update.  We’ve started digging into this, and it looks like a couple of extra HTTP requests have snuck into this page – a JS file and a sprite or two.  We’ll be consolidating these requests in the coming days and we expect to see the document complete time on this page drop back down.

As far as the rest of the improvements go, we believe that they are due to a combination of changes that we’ve deliberately made to improve performance, and a better hit rate at our CDNs.  We are currently load balancing static content across multiple CDNs, and we’ve worked to improve cachability so that fewer requests have to hit our origin.


Overall we are happy with the way performance has been trending, especially because we’ve been focusing our efforts over the last 4 months on projects that don’t involve these core pages.  For the next couple of quarters our plan is to establish clear performance SLAs and bring all of our major pages into compliance with them.  Beyond that we are always looking for big wins and evaluating new standards like SPDY, WebP, and pre-fetching to see if they make sense for Etsy.  It’s an exciting time to be working on web performance!

Does this sound like something you would like to work on?  Our team is hiring!

You can follow Jonathan on Twitter at @jonathanklein

Posted by on April 9, 2013
Category: performance


Glad to see continued improvements. Well done.

Help me understand, is this strictly page load time (no network response time) and is this a cached response or non-cached result?

    The server side performance numbers are pure page load time, as reported in our Apache access logs.

    The front-end performance numbers are full page load time, so the time between the initialization of the request in the browser and the firing of the relevant event (start render or document complete). These numbers are for first page views (nothing cached) on a DSL connection.

    Let me know if you want more detail on this!

Very cool, and pretty. Did you generate these charts manually or do you have a tool that does so? I’m interested in getting as much detail as needed to replicate.

    We actually have one of our designers make the charts for us, so we are pretty luckily in that regard. You could use something like Google Charts to keep things easy in the beginning.

Hey Jonathan!

I noticed you’re using the sync (rather than async) version of Google Analytics. I wrote up a Gist that might refractor / shave off a few milliseconds globally if it’s in your footer.

StrongerMaybe.html — Best rec for loading GA Async and not delaying your $(document).ready calls

Maybe.html — Not sure what the requirements around Etsy.GA.track() are (maybe it’s scattered throughout some of your confirmation/order code or too hard to completely refractor out). This pattern might be best as an stepping stone. You can “push” the function to load everything in GA using your current sync pattern, but it will load asynchronously.

Current.html — What you currently have live

Would love to see it live hear feedback! Always enjoy your progress reports / updates


    Hi Tom,

    This is something that we are aware of, and we’ve been working towards switching over to the async snippet. Unfortunately we still have some Etsy specific analytics that piggybacks on top of the Google Analytics cookie, so we have to be sure that the cookie is present early in the page load process. We are working on a project now to refactor this code so we can switch to the async snippet. It’s high on our list!


Just a quick comment on your gist snippet, you no longer need to use http/https prefix when including remote assets such as javascript.

Simply do //.

Hi Jonathan,
Interesting article! Which tools do you use to measure page load speed?

    For the backend metrics we use load time data from our Apache logs. For the front-end we have a private WebPagetest instance, and aggregate the data from those tests. Happy to provide more detail if you are curious!