clock menu more-arrow no yes mobile

Filed under:

Declaring performance bankruptcy

Over the last four years, Vox Media has made a name for itself by building big beautiful sites and filling them with high-quality, feature-rich content. We’ve spun up six completely custom properties, redesigned our largest community (SB Nation), and refactored The Verge to be fully responsive. During that stretch, our workflow could best be described as "launch mode," where our main priority was to ship first and iterate later. However, with the limited number of people on our Product Team, we often had to move on to the next big project before we had time to fully polish and optimize our latest release, leading us to accumulate a rather significant amount of performance debt.

Look, we know our sites aren’t as performant as they could be… I mean, let’s cut to the chase here... our sites are friggin’ slow, okay! Performance metric tools often use our render time to show off the upper limits of their graphs!

So you might be asking yourself, "why does Vox Media hate performance? Are they just doing this to punish me or what?!" Well, my friend, I’m here to tell you that we do care about performance. We care about it SO HARD that we’re publicly declaring performance bankruptcy.

In all seriousness, this post isn’t about poking fun at our performance numbers (despite how cathartic it feels to clear the air). We’ve finally reached a tipping point where we can devote full-time resources to the performance of our platform, and we want to bring you along for the ride. This post will introduce you to our newly-formed Performance Team and describe the first steps we're taking in pulling ourselves out of performance bankruptcy.

The Vox Media Performance Team

Our Performance Team is currently made up of Jason Ormand, Ian Carrico, and myself, but we want to make it clear that we’re not the sole arbiters of optimization. Good performance is everyone’s responsibility; from designers to developers, ops to ads, to editorial and beyond. If we do our jobs well, everyone will be more informed about how their decisions affect the overall performance of our platform. We plan on releasing performance reports at least once a quarter right here on the blog, both to keep our team informed and allow our readers to follow along with our progress.

This introductory post will stand as a sort of proto-performance report. A line in the sand that we can compare our progress to and see how far we've come; and trust me when I say we have a very long way to go.

What does performance bankruptcy mean?

In a nutshell, it means we're consolidating all of our performance debts and working holistically to get back in the black. The first step in the process is to take an honest look at where we're starting. After all, you can't pay off your debts if you don't know what they are. Here’s a sampling of our current performance metrics*:

  • 4.85 seconds to first paint
  • 23.33 seconds to page complete
  • 13,406 speed index

* these numbers represent the two-week average between the six properties that are being served from Chorus: SB Nation, The Verge, Polygon, Vox, Eater, and Racked.

Ouch. As you can clearly see, we've got a lot of work ahead of us, so the next step is to set up a budget. To start things off, we're going to set up a generalized set of metrics to hit across all of our pages. Here's the first set of goals we're aiming for:

  • 2 seconds to first paint
  • 8 seconds to page complete
  • 4,000 speed index

While these numbers represent a significant and ambitious bump in performance, they're only the beginning. Optimization is a process, not an event. Once we hit these goals, we'll start tweaking the numbers and setting up specific budgets for different pages types (e.g. smaller budget for plain article, slightly larger budget for media-heavy pages like gallery and video pages).

As our Chief Product Officer, Trei Brundrett, said at a recent talk, "I’ll never be satisfied with the speed of our products. It’s never, ever fast enough." In keeping with that sentiment, we'll continue optimizing and tweaking our sites until every last performance gain has been wrung from our platform.

What do we have planned?

There’s an old saying that goes something like, "the best time to plant a tree was 20 years ago, but the second best time is today." In an ideal world, we would’ve been thinking about and planning for performance more than four years ago, but that simply wasn’t the case. Fortunately, we’ve learned a lot about our traffic and performance over that stretch of time, and we’re ready to start implementing best practices and optimizations today.

For instance, until recently our static assets (i.e. stylesheets and javascript) were being served from different CDN subdomains via domain sharding. This was problematic since it required a separate TCP handshake for each request that wasn't on the same subdomain. One of our first projects was to consolidate the asset calls to a single subdomain, allowing us to download multiple files in parallel without needing the additional round trips.

While this optimization might not move the needle drastically, it's a step in the right direction. As Jason Ormand, one of Performance Engineers, put it, "small things like this is like finding a couple bucks in your couch; it's not going to change your life but it makes you kinda happy."

We've got a full backlog of similar optimizations, both big and small, including things like:

  • Consolidating and optimizing our font delivery system
  • Ad delivery and asset tweaks
  • Auditing and removing non-critical assets from the critical path
  • Adding on-page metric monitoring via justice
  • Developing our own internal performance-tracking tool that surfaces important metrics for the entire company to see and understand

And that's just the tip of the iceberg. The performance team is spun up and 100% invested in making Chorus the fastest content delivery system on the planet. We hope you're as excited for these optimizations as we are, so stay tuned to this blog to follow our progress.