Will-Sommers/gist:33532c72be7a1759332b

## gistfile1.txt
We have a performance problem

Around 6 seconds.

This number belies two points. The first being that our site is slower than we would like it to be. The second is that it is not exact and gives us no idea of directionality. I’ll talk about each, in turn.

Our site is too slow.

Why in the age of cheap RAM, fast connections and copious caching is this the case. It should also be noted that while we are transitioning away from a separate mobile-only site, that the “around 6 seconds” number represents only our desktop users.

So, what are the reasons behind this number?

Personalization, allowing for less caching
High weight pages and specifically images
A quick moving team(and a need for better measurement)

While on the face of it, our site appears to be a regular e-commerce site, a hotel or airline reservation website would be a better comparison. We rent goods for a set amount of time to our customers across the United States. Unlike regular e-commerce sites where inventory runs are large and availability is easy to know, we need to know, quite early in our funnel, where our customer would like their dress shipped. Especially when our customers are reserving a dress for a few days out, this information is very important and is difficult to cache.

Our site is also quite high weight at the moment. This is in part due to high weight images, for a comparison, our site has around the same number of images on our homepage, excluding marketing pixels. Here are the numbers for our homepage, with Etsy’s homepage as a comparison:

RTR - 76 requests, 1.6 MB
Etsy - 57 requests, 384K

The Javascript on our pages is quite heavy as well. Here are the numbers:
RTR - 26 requests, 510KB
Etsy - 16 requests, 183KB

We can do better than this and will. While, in late 2014, I focused on making some of our server-side calls faster, my manager Jade kept saying, “Look at the images.”

Rereading the arguments behind the two previous points, I’m struck by the fact that these are not insurmountable problems and are in some cases quite common for startups of of our size. We’ve been moving very quickly and focused on growing our business and spent less time optimizing our site. This was the right decision. In 2014, for example, we moved a large portion of our team to focus on creating a product, our very successful RTR Unlimited Program.

Around 6 seconds

The second point I mentioned is that our numbers are sort of hazy and technically, this probably isn’t true. New Relic gives us a great deal of metrics. For example, we can see in the graph below that our users experience an especially poor experience over the weekends and during the evening. We can see, in particular, that page rendering and DOM processing are quite slow. We’re betting that this is due to page weight on our grid pages specifically.

What New Relic doesn’t give us is information to answer the following questions:

How many requests are made per page load?
How many DOM elements are on our home page?
What is the directionality of the previous two questions over the last month? Three months?

Webpagetest is a really great resource for this and I think that a private instance could really help our team measure how our site is performing over time. While this is not “Real User Monitorying/Testing”, it will give us granular data that we can use to tune our site. This data will also serve as a starting point for conversations with UX and design when new features are discussed.

A promise

This year we’ve created a web platforms team to focus on issues like performance. If you’re a customer of Rent the Runway reading this blog post, please take this promise to heart. We will make our site experience faster and better. We will update you on our progress in the coming months as our web platforms team takes off.

Lastly, I want to thank the Etsy team and their Code as Craft blog writing and speaking on this topic
	We have a performance problem

	Around 6 seconds.

	This number belies two points. The first being that our site is slower than we would like it to be. The second is that it is not exact and gives us no idea of directionality. I’ll talk about each, in turn.

	Our site is too slow.

	Why in the age of cheap RAM, fast connections and copious caching is this the case. It should also be noted that while we are transitioning away from a separate mobile-only site, that the “around 6 seconds” number represents only our desktop users.

	So, what are the reasons behind this number?

	Personalization, allowing for less caching
	High weight pages and specifically images
	A quick moving team(and a need for better measurement)

	While on the face of it, our site appears to be a regular e-commerce site, a hotel or airline reservation website would be a better comparison. We rent goods for a set amount of time to our customers across the United States. Unlike regular e-commerce sites where inventory runs are large and availability is easy to know, we need to know, quite early in our funnel, where our customer would like their dress shipped. Especially when our customers are reserving a dress for a few days out, this information is very important and is difficult to cache.

	Our site is also quite high weight at the moment. This is in part due to high weight images, for a comparison, our site has around the same number of images on our homepage, excluding marketing pixels. Here are the numbers for our homepage, with Etsy’s homepage as a comparison:

	RTR - 76 requests, 1.6 MB
	Etsy - 57 requests, 384K

	The Javascript on our pages is quite heavy as well. Here are the numbers:
	RTR - 26 requests, 510KB
	Etsy - 16 requests, 183KB

	We can do better than this and will. While, in late 2014, I focused on making some of our server-side calls faster, my manager Jade kept saying, “Look at the images.”

	Rereading the arguments behind the two previous points, I’m struck by the fact that these are not insurmountable problems and are in some cases quite common for startups of of our size. We’ve been moving very quickly and focused on growing our business and spent less time optimizing our site. This was the right decision. In 2014, for example, we moved a large portion of our team to focus on creating a product, our very successful RTR Unlimited Program.

	Around 6 seconds

	The second point I mentioned is that our numbers are sort of hazy and technically, this probably isn’t true. New Relic gives us a great deal of metrics. For example, we can see in the graph below that our users experience an especially poor experience over the weekends and during the evening. We can see, in particular, that page rendering and DOM processing are quite slow. We’re betting that this is due to page weight on our grid pages specifically.

	What New Relic doesn’t give us is information to answer the following questions:

	How many requests are made per page load?
	How many DOM elements are on our home page?
	What is the directionality of the previous two questions over the last month? Three months?

	Webpagetest is a really great resource for this and I think that a private instance could really help our team measure how our site is performing over time. While this is not “Real User Monitorying/Testing”, it will give us granular data that we can use to tune our site. This data will also serve as a starting point for conversations with UX and design when new features are discussed.

	A promise

	This year we’ve created a web platforms team to focus on issues like performance. If you’re a customer of Rent the Runway reading this blog post, please take this promise to heart. We will make our site experience faster and better. We will update you on our progress in the coming months as our web platforms team takes off.

	Lastly, I want to thank the Etsy team and their Code as Craft blog writing and speaking on this topic