The Metric System: Making Correct Performance Measurements

Some who have been present on the web a little whilst might still remember one of the preeminent debugging tools: FireBug. For all its features and early praise, its author Joe Hewitt initially created it for 2 reasons: to observe what was happening on a page, pre and post resource load. Two simple metrics.

A decade and change later, measuring resource loading and page performance is in equal parts proof and perception. The multitude of metrics available has allowed for granular measurements, but has also clearly created confusion.

During ‘The Metric System’, we will learn about many of the performance metrics being bandied around like FCP, FMP, TTFB and Speed Index to name a few. But more importantly, we will see how to interpret this data, when to use it in order to extract the information our individual users need for the best user experience possible.

(No it’s not really his last name 😉 But it’s a great nom de plume!)

Evolution of web development doesn’t come without evolution of the web itself. The web wouldn’t be where it’s at today without evolution of the web browser. In the early days there were spirited debates about whether including images was a good idea, as it would potentially encourage the wrong kind of content and publisher. But in the end the evolution opportunities won out.

A lot of evolution has been around resource loading. The Firebug tool was created to tell you what was happening when your page first loaded, then what happened after that. It was an early example of starting to really measure performance, which is important because you can’t improve what you can’t measure.

Anything you can measure is essentially a metric. Metrics let you create comparisons.

metric: (noun) a system or standard of measurement

So what are the correct performance measurements?

Chart of W3C

W3C performance timing information

When first presented with this wall of numbers, it was hard to draw much from them.

  • onLoad was a huge number that people used to use very heavily, but it does not convey a lot about modern experiences.
  • ttfb time to first byte gives an insight about the backend
  • startrender gives an indication of when the user may start seeing pixels painted to the viewport.
  • speed index this is a visual representation of the load, it looks like a film strip. It gives a way to understand the visual experience during load. It gives an idea what happens towards Visually Complete Progress. The speed index calculates a number based on how long the page spends unrendered on the way to visually complete.

Page performance is in equal parts proof and perception.

Performance is still hugely important because the next billion will be arriving on low powered phone handsets. In late 2016, mobile usage exceeded desktop usage for the first time. Emerging markets have a very high proportion of people on phones that can’t handle heavy content, or it will be prohibitively expensive to download the data.

So what newer metrics can we find?

Paint metrics:

  • First paint – this is when the browser first rendered after navigation, excluding default background render.
  • First contentful paint – the first time the user can start consuming content.
  • First meaningful paint – the paint that follows the ‘biggest layout change’. This metric is so broad and fuzzy it may go away and be replaced with the largest contentful paint.

Interactivity metrics:

  • time to interactive – rendered and reliably usable/able to respond to user input
  • first input delay – measuring the time from when the user first interacts with the page, to when the browser is able to respond to that interaction

Experimental metrics – these get quite interesting…

Can we track the largest image on the page, or the biggest heading? A news website will really want to measure when the article’s headline loads. How can we detect or define the ‘most important’ content?

Load is not one single moment, it’s an entire experience. – Phil Walton

Using good tooling will lead you to the right things to investigate. The Web Directions site is mostly great, but there’s a long time to first byte. So you know where to look to speed that up (the server). WebPageTest shows A ratings for all the other metrics, so overall it’s in good shape.

Where web performance is concerned, you can’t improve what you can’t measure. Use tools to give you insights into what’s going on, then ask questions about what you can do to improve.

Tools and sites mentioned: