Matt was supposed to write this, as it’s something he’s got a lot of passion about, but he’s busy on a sweet new project. Read all the way through to see both how significant the improvements are, and how serious Matt’s commitment to the challenge has been.

I mentioned yesterday that the server-side page generation time has been dramatically improved with our new theme, here are some numbers on the improvement in the browser. First up, take a look at the improvement in the number of requests in the following chart. The waterfall page does just 35% as many requests as it used to, but even the single pages are down to 60% of the previous number of requests:

Number of Requests (count)

The improvement in total page weight is even more dramatic. The three page types are just 10% or less of their former selves, having lost most of their bits with the new theme:

Total page weight (megabytes)

Altogether, the reduced page weight, fewer requests, and faster server-side times yield a dramatic improvement to the time it takes for our new site to appear in the browser. We’re seeing a 3.5X to 4.7X performance improvement in our tests of single and waterfall pages. Search pages are a little better too.

Time to DOMContentLoaded (seconds)

John Gruber laid down a gauntlet a while ago when he called out others for bad performance. Jim Dalrymple shared the numbers on Gruber’s own site (yes, we were watching):

Daring Fireball: 23 requests; 49.82KB; 566 milliseconds

So, we’re not quite down to Gruber’s svelte size and times, but our 81 requests, 999.51KB, and 726ms isn’t bad.

Getting these numbers took some work, and it meant making performance a goal from the start. Our old theme was designed and built in a different era, and we learned a lot by trying to bolt performance on after the fact. In fall 2010, before Matt joined GigaOM, he did an assessment for us on how we could do better. The comparison times from the old theme in the charts above are after we’d applied many of those suggestions and more.

So how did we do it? You’ve heard of these techniques before: replace images with webfonts, concatenate, move JS to the bottom, lazy-load, and get rid of third-party JS includes. One very visible aspect of that: we’re not using the official tweet, like, or Google+ buttons. That eases concerns about the NASCAR-ization of our site with other people’s logos and offers some privacy improvements, but from an engineering perspective the biggest win is the dramatic improvement in page load and rendering times.

  1. [...] to another site, maybe Twitter or LinkedIn, where that site prompts you to complete the share. This makes our pages load faster, and offers our readers more privacy and security than using the more common Javascript sharing [...]

    Reply Share