Performance Update #3: Line Rider Edition

I can’t believe it’s been six months since our last official performance update, and nearly a year since we originally declared performance bankruptcy. I guess It’s true what they say, "time flies when you’re optimizing an array of ad-supported custom media sites!" Who said that, you ask? I believe it was Mark Twain, actually, but we’re not here to talk about famous musicians. No, we’re here to highlight some of the stellar work the Performance Team has been toiling on over these past few months. So let’s jump right in!

Thumbor integrations

In our last update we talked about integrating WebP and Thumbor into our sites, but the image optimization work didn’t stop there. We’re currently in the process of building two more Thumbor plugins that should help us shrink our image sizes even more.

The first plugin analyzes PNG images (which are notoriously large) for alpha transparency, and if it doesn’t find any will return an optimized JPEG version. This format transformation will save bandwidth and, unlike WebP which only affected Chrome browsers, should benefit everyone.

The second Thumbor plugin is still in the research and experiment stage, but has the potential to save us even more bytes by dynamically changing compression amount on an image-by-image basis. The goal is to make our image processor "quality aware" so certain images can be compressed more aggressively and have the result be indiscernible (at least by humans) from the original source.

If these plugins are a success, the changes will be felt in page weight rather than image quality.

Picture Element

Image optimization isn’t only about compression settings and format detection; we’ve also been busy tweaking how article images are prioritized within the critical rendering path. For the last several years we’ve relied on custom lazy loading javascript to both render and select the appropriate ratio and pixel density for most (if not all) of our inline images. While this technique kept the DOM tidy and allowed non-image content to load faster, it also incurred the cost and latency of multiple AJAX requests and didn’t use preloading for important images (e.g. lede images on articles).

To solve these issues we turned to native picture elements -- specifically srcset with format selection -- which is responsive, loads WebP, and leverages the preloader. While it’s not a perfect solution due to DOM bloat and automatically loading images outside of the viewport, we felt the performance wins outweighed the cons.

Ad performance testing

Ad performance is a big deal to our team; so much so that we embedded a Performance Engineer within the team that’s responsible for building and delivering our internal ads. Since then, he’s helped build an automated testing suite that uses WebPageTest to track each ad’s metrics against our performance budget. The data from these tests is processed and displayed on an easy-to-understand dashboard (using multi-colored rockets!) so ad-creators and non-developers can quickly identify ads that need updating.

This is just the tip of the iceberg for the performance work we’ve done, and are continuing to do, with ads. After all, fast ads are the best ads.

Server response optimizations

Our Operations Team continues to push our server performance to the MAX. By optimizing Varnish and placing our www behind Fastly’s CDN, we’ve seen a 400ms reduction in backend response times over the last year.

Project Unison + Presto

If you’ve been following this blog, you know we recently relaunched Curbed on a brand new front-end framework called Presto (note: if you haven’t already, check out these great articles that go into more detail). This new system represents a complete refactor of our front-end architecture and was built, from the ground up, with performance as a top priority. Although Curbed has only been live for two weeks, and we still have more optimizations to make, the early returns are amazing:

After launching Curbed on Presto, our performance graphs looked like this:

To better illustrate that drop-off, I traced one of the graphs in LINE RIDER and this was the result:

As of today, Curbed (launched two weeks ago) and Vox Media (launched yesterday) are the only two sites running on the new Presto framework. As more sites move onto the new framework, we’ll start to see these performance wins spread across the entire Vox Media network. To approximate how much faster Presto could make our other sites, I averaged the metrics of our three largest brands (SBNation, Verge, and Vox) and compared them against Curbed’s:

As you can see, we hope to realize some significant improvements over the coming months as we transition all of our brands onto the new framework.

TECHNICAL NOTE: Our performance data is derived from synthetic testing that's configured to emulate 3G speeds (1600 kbps down, 768 kbps up, 300 ms latency). Mobile performance is a huge priority for us, so we test and track against slow mobile speeds first.

More to come

The Performance Team's job is never finished. Until our sites load at the speed of causality, our work must continue. If you've read this far (hi mom!) and have any questions about the Performance Team or our work, please leave us a comment. I'd also like to thank Jason Ormand and Ian Carrico, our two intrepid Peformance Engineers, for their stellar work and contributions to this article. Thanks for reading!