A simple, client-side approach to measuring Speed Index

When I first started learning about web page performance, I always use to focus solely on the time that it took a page to load. The excitement of seeing a web page load in an instant kept me coming back for more. Whilst web page load time is an important metric to measure, it doesn't tell the whole picture. As I started to learn more about web page performance, I started to experiment with webpagetest.org and discovered the different metrics that it uses. One of the metrics produced when you run a test using webpagetest.org is called Speed Index and it changed the way I thought about web performance.

Speed Index is important because it goes a step further and measures how much of the "above-the-fold" content is visually complete until the web page has finished loading. In order to measure the Speed Index of a web page, each frame of the page load is compared against the final loaded frame to determine their percentage completeness. The Eggplant website does a great job of explaining clearly how Speed Index is calculated.

"Each frame is given a score for visual incompleteness above the fold. So the score is 100 per cent for a blank screen and 0 per cent for a visually complete page. The next step is to multiply that score by the number of milliseconds since the last frame. The final step is very easy: add these numbers together. The total is your Speed Index score!"

Until now, it's only really been possible to calculate the Speed Index metric by comparing the frames in a video using webpagetest.org. That is, until the legend himself Pat Meenan created a client side library that calculates the Speed Index for a given page.

In this article, I am going to show you how to get started using the Speed Index library and how you can start collecting this data using Google Analytics. If you'd like to see a working example of this in action, please head over to deanhume.github.io/speedindex-test.

Under the hood, the Speed Index library is really clever. You simply include the library on your web page and then it starts collecting a list of visible rectangles for elements that loaded external resources - for example any images, background images or fonts. Next, it records the time it takes for the external resources for those elements to load using the Resource Timing API. It calculates the likely time that the background painted and finally it runs the various paint rectangles through the SpeedIndex calculation.

Getting started

It's worth noting that the library is still in the early stages and hasn't officially been released, but that's no reason why you can't start experimenting with it today! Get started by including the script in your web page.

The code above is pretty straightforward and will calculate the Speed Index for your webpage and display it in to your Dev Tools console. This is pretty cool, but we can do so much more with this data! If you start collecting this data from the field, you'll be able to build a better picture of your web page performance using Real User Monitoring (RUM).

Collecting the data

Now that you are collecting the Speed Index for your web page, you could push the data to your web analytics tools or even test for this in a performance budget. I personally use Google Analytics to keep a close eye on my websites and in this example, I am going to show you how you can start pushing the Speed Index results to Google Analytics.

If you aren't familiar with Google Analytics, you can sign up for a free account at analytics.google.com. Once you've signed up you can use the tracking script and include it in your web page.

In the code above, you'll notice around line number 14 that I am sending an event to Google Analytics and including the RUMSpeedIndex value. That's it! Your webpage is now calculating and tracking it's Speed Index. If you navigate to your Google Analytics account, the values should start to filter through. If you'd like to learn more about event tracking in Google Analytics, I recommend heading over to the Google Analytics Developer Website to find out more.

What Speed Index score should I be aiming for?

Speed Index can be a tricky score to understand at first. Contrary to what you might think, the lower the score, the better. Remember it's a metric that is used to the measure visual complete of a web page, so a higher score would mean it took longer to visually complete.

But what score should you be aiming for? Well, Paul Irish recommends a Speed Index of under 1000 in order to deliver the above-the-fold content in the first 14kb of the page. However, that score can be pretty hard to achieve for the average web page. In order to get an idea of the large majority of websites out there, the NCC group ran a test of the top 50 UK retailer home pages. They found that the average score was 3000 between and 8500.

Further thoughts

This Speed Index library has been around for probably close to a year, but I am keeping a close eye on it to see how it progresses. As with any new library, there are a few things to be aware of:

• It only works for browsers that support Resource Timings (most modern browsers except Safari)
• It doesn't handle content within iframes (possible, just not implemented yet)
• Works better for IE and Chrome which both support reporting a "first paint" event

That said, this is still an awesome library and definitely worth experimenting with! It's worth noting that your mileage may vary and you should test it in webpagetest.org as a custom metric and compare it to the real video speed index to see how well it works for your site before trusting the results too much. All of the code in this article can be found at github.com/deanhume/speedindex-test. It's an open source initiative, so feel free to contribute!