It’s been three months since we officially declared performance bankruptcy, which means it’s time to assess and highlight some of the optimizations we’ve made over that time. Our focus has been on improvements at both the micro and macro level, but there’s still a lot of work to be done. Today I’d like to detail some of our more impactful projects and talk a bit about how we’re prioritizing performance across the company.
Completed Projects
Over the last few months we’ve steadily chipped away at our sites’ page load time, resulting in a distinct downward trend across the entire network. The following graph shows network-wide page load times dating back to when we declared performance bankruptcy to mid-July.
Over the entire network, between mid-April and now, we've seen the following increases in performance metrics:
- Average start render time went from 5.3 to 2.6 seconds (51% faster)
- Average page load time went from 22.8 to 11.5 seconds (50% faster)
- Average fully loaded time went from 27.9 to 15.2 seconds (46% faster)
These numbers reflect the average between all six sites that are currently running on Chorus (if you'd like to see the performance breakdown for each vertical, take a look at this spreadsheet), and are a direct result of numerous micro optimizations and the following big projects that were aimed at moving the needle in a big way.
Font delivery optimizations
As we launched new websites over the last three years, the way we handled custom fonts had become fragmented and problematic. The majority of our sites were loading fonts in an inconsistent manner, and (even worse) were calling fonts that were only used once or not at all. This was creating a burden for both our engineers and, more importantly, our audience.
Our first step was to audit and remove redundant and under-utilized fonts. Next, we implemented Bram Stein’s Font Face Observer across Vox, Eater, and Racked and started loading their fonts asynchronously. Early results have shown a 500ms decrease in page load times, but an even faster perceived load time since fonts are no longer blocking page render.
Webp integration
Across all of our sites, our largest browser share belongs to Chrome, which means we were leaving bandwidth on the table by not using WebP. If you’re not familiar with WebP, it’s a new image format developed by Google that can deliver lossless images up to 25% smaller than PNG, and lossy images up to 34% smaller than JPEG. By using this new format, we’re able to save money on bandwidth by sending fewer bytes across the wire to our largest subset of readers, and users benefit from faster load times since the images are significantly smaller. It’s a win-win situation in every sense of the term!
We’re now running image requests through Thumbor and a bit of client-side logic to serve up WebP whenever possible. So far we’ve seen decreases in page load time ranging from one to three seconds, with a corresponding reduction in page size of one to two megabytes. These early results are partially handicapped as a result of us not passing all of our image assets through the new Thumbor/WebP process. As we get more images piped into the new flow, we expect the load times and page sizes to decrease even more.
CDN research and testing
One of our responsibilities on the Performance Team is to future-proof our platform so we can leverage potential optimizations as they become available. To that end, we wanted to make sure our CDN was SPDY or HTTP/2 compatible, so we worked closely with our Operations Team team to analyze and test several competing CDN solutions. After plenty of due diligence, we’re primed to move to an HTTP/2-compatible service in the very near future, which will allow us to leverage all the advantages that H2 brings to the table. If you’re curious about the performance benefits of SPDY and HTTP/2, check out this Verge article from earlier this year.
Internal tools for gathering and sharing metrics
It’s impossible to gauge the success of optimization work without having access to a good metric-gathering tool. We’re big fans of Speedcurve and have been using their service for the last few months, but we’ve also been toiling on our own internal solution, which we call Tempo, that will allow us to take an even deeper look into our performance stats.
Tempo uses a private WebPageTest instance to test each of our verticals and allows us to track performance metrics and compare results between recent deploys. It’s still in the pre-pre-beta stages, but once we get it to a suitable level of stability, we plan on open-sourcing and sharing it with the performance community at large.
Across the company
The Performance Team isn’t the only place where big strides are being made to improve the speed of our platform. Vox has embraced performance as a top priority, with several teams already working on their own specific optimizations.
Advertising
Our Revenue Team is increasing focus on the impact our advertising has on user experience and overall performance. One of their biggest initiatives has been to change the way ads load from synchronous to asynchronous, which has been underway for several months and is nearing deployment. The biggest advantage of loading our ads asynchronously is summed up well by this quote from Google:
"The advantage of the asynchronous code is that it's guaranteed never to get in the way of other parts of your web page loading. This means that users will be able to load the content of your pages, even if they’re having trouble loading the ads. Mobile users in particularly will enjoy less latency when loading web pages."
They’re working on several other projects to address not just performance, but the impact to the overall user experience. They will be sharing details here very soon.
Chorus
Our Platform Team is continually iterating on our publishing platform to make it the best in the industry. Their current work has been focused on overhauling and unifying the front-end audience-facing presentation layer of Chorus, with a renewed priority on performance. The Performance Team has been involved with this work from the earliest stages to help create and enforce an aggressive but achievable performance budget. As this effort continues and we start to migrate our brands onto this new optimized framework, we'll not only be improving their current page load times -- we'll also be making it easier for our teams in the future to apply optimizations that benefit all brands running on Chorus.
Operations
Beyond the aforementioned HTTP/2 research, our Operations Team is working to add points of presence to increase our system capacity during high-traffic situations and reduce content delivery time for many users
More to come
As we’ve mentioned in the past, good performance isn’t an end goal, it’s a continual journey. We’ve seen some good returns on our early work, but we still have a long way to go before we’re consistently performing within our budgeted limits. We’ll keep dropping updates as we move along, and we hope you’ll follow along with us on the journey.
UPDATE: The original speed improvement percentages weren't very clear. I've updated the formulas to calculate those numbers and replaced them in the post. Thanks to Chris Chan for helping us clarify!