add before and after

Author: i8ramin

_drafts/wework-com-is-going-static.markdown

@@ -81,10 +81,18 @@ There are many different ways to skin this cat, ranging from installing and conf
 
 We found one host that met all of those requirements and more, and they are called [Netlify](https://www.netlify.com/). Never heard of them? Neither had we, but as a colleague of mine recently put it, "Netlify is like the developer whisperer". This team has put together an amazing service that handles SO much for you from a dev-ops persective of hosting static sites. And if there is a feature that is missing, they will bend over backwards to either implement it for you, or help you figure out a solution. I can sit here and sing their praises all day long, but its probably best if I explained a bit about how they were able to help us with our migration to a static site and make the static verions of our site *2-3x faster*.
 
-To get started, one of the first pages we decided to migrate over to static was our [`/locations`](https://www.wework.com/locations/) page. This page doesn't get a ton of traffic, but has dynamic content coming from our backend, so it seemed like a good place to start. We no longer have the old version up now, so I can't do a side by side comparison, but just looking at the graph below you can see the downward trend (in the world of performance, downward trending graphs are usually a good thing) from the day we rolled it out. Our server response time is **1ms** (this number is around 150-200ms on other, non-static pages) and the page is visually complete in about 2.8 seconds, which is 2-3x faster than it used to be. Of course, we've done other optimizations as well (reducing unused assets, optimizing images, etc) and there are still other things we can do to make it even more performant, but we are very pleased with the results so far.
+To get started, one of the first pages we decided to migrate over to static was our [`/locations`](https://www.wework.com/locations/) page. This page doesn't get a ton of traffic, but has dynamic content coming from our backend, so it seemed like a good place to start. Looking at the graph below you can see the downward trend (in the world of performance, downward trending graphs are usually a good thing) from the day we rolled it out. Our server response time is **1ms** compared to 150-200ms on other, non-static pages. The page is visually complete in about 2.8 seconds, which is 2-3x faster than it used to be. Of course, we've done other optimizations as well (reducing unused assets, optimizing images, etc) and there are still other things we can do to make it even more performant, but we are very pleased with the results so far.
 
 ![Performance graph of locations page](http://res.cloudinary.com/wework/image/upload/c_scale,f_auto,w_1000/v1448740493/engineering/locations-graph.png)
 
+And here is a before and after from the Chrome inspector showing some impressive before and after numbers:
+
+##### Before (non-static)
+![Locations - before](http://res.cloudinary.com/wework/image/upload/c_crop,f_auto,g_north_east,h_30,w_550/v1448908828/engineering/locations-before.png)
+
+##### After (static)
+![Locations - after](http://res.cloudinary.com/wework/image/upload/c_crop,f_auto,g_north_east,h_30,w_550/v1448908829/engineering/locations-after.png)
+
 So how are we serving up traffic to `wework.com/locations/` from the static host and other pages from our current non-static host? It was as simple has modiftying some DNS settings to route all traffic through Netlify, [creating a `_redirects` file](https://www.netlify.com/docs/redirects) at the root of our very basic static site, with some rules about which URL's to pass through and which ones to handle. Netlify's proxy and rewrite is actually very intelligent in how it handles requests. If it finds the file, folder or resource locally in your folder structure, it will serve that up before it tries to proxy it. On our site, we have a catch-all rule that looks like this:
 
 ```coffeescript