If you’re new to this whole ‘web performance’ craze, you may have noticed that it can be quite complex.

Should you measure load time? Responsiveness to user inputs? Page-to-page navigation? Do you do this for users in the Democratic Republic of the Congo, or Silicon Valley? Fiber, 4G, loon? On a Moto G4 or an iPhone 7? And which browser — one that supports preload and HTTP/2, or something a little more retro?

Will you measure a user’s first ever visit to your site, or a return journey when their cache is nice and primed?

And will you be reporting on the average load time? (Absolutely not. The whole concept of the ‘average’ is yet another thing that Newton got wrong.) So maybe you’ll report on the median, or perhaps display a histogram of what the users actually experience?

A reasonable person might come the conclusion that this is all a bit hard, and put it on their ‘tomorrow’ list.

But it doesn’t need to be so complex, as I hope to demonstrate in this post.

Following in some footsteps

Last week, I was deep in a perfyoga session (perfyoga is like normal spandex yoga, except you replace the stretching part with the Chrome DevTools) when it dawned on me: there’s another industry that faces exactly this conundrum.

An industry with a need to boil down a complex concept such as ‘performance’ into a single metric that can be discussed and compared and tracked over time.

The automotive industry.

There are an endless number of things to take into account when measuring the ‘performance’ of a car. If you asked 10 car enthusiasts to define performance you’d probably get 10 different answers, and would be thoroughly bored by the end of the process. Just like you are with this paragraph.

You can measure top speed, acceleration, Nürburgring lap time. With cold tires or warm, half a tank of fuel or full, race driver behind the wheel or Mr Bean (I wonder… when Mr Bean crashed his McLaren, did he have to convince the insurance company he wasn’t sitting on the roof in an armchair steering via rope at the time?).

But the car industry wisely realized that if you want to have any sort of discussion and comparison of performance, you need to pick a number and stick to it. For cars, it’s the time it takes to go from 0 to 60 mph (or 100 km/h if you’re in one of the sensible countries).

So why not follow suit when trying to measure the performance of your web site? Put aside all the complexity, accept that you can’t capture everything at once, pick a number, and stick to it.

Multiple meanings of measurement

But I’m not suggesting that the only thing you ever need to measure about a web site’s performance is one single number. I’m not some sort of crazy person (despite what the orderlies allege).

Story time: I was watching a video recently, the fellow on stage was talking about ‘speed indexes’ when it struck me — like a goose to Fabio’s face — that the word ‘measure’ is used to refer to a range of different things, that serve vastly different purposes, and perhaps this is where a lot of the apparent complexity comes from.

So I think it’s worth picking apart these different meanings — like Fabio picking foie gras out of his golden locks — because this might save you from trying to ‘measure’ something in a way that it doesn’t need to be measured.

If you ask me (and you kinda did by reading this), ‘measuring performance’ can be separated into two things:

A single measurable number that can be used to support a discussion about performance. It can be used to set priorities, and be tracked over time. It is an indicator of overall performance, and does not aim to capture all the nuance of a site’s performance. I will call this the “ key performance indicator ”.

”. On the other hand, we need something to help us, the web developers, understand where time is being spent loading our site, in all different conditions, and to guide us when improving performance. It doesn’t need to be recorded or reported in any formal way. I will call this the “ad hoc assessment of factors impacting a site’s performance with the aim of improving said performance”. Snazzy.

This post is all about the former — hence the title promising simplicity. But with regards to the second one, I’ll give you some bullet points and a link at the end.

The key performance indicator

This is your 0–60 mph time. Some characteristics:

It should be simple — a single number.

It should be relevant to your site — to your users.

It should be measured in a consistent manner.

It should be understandable to non-developers.

Let’s say, for your KPI, you decide you will measure the time it takes until a user can begin reading the text on your page. Imagine this is 4.2 seconds for your home page.

4.2 seconds should be a number that The Head Honcho knows and cares about, that your marketing team talk about, that the SEO chap cares about. It should be written large on a whiteboard in the office. Everyone should be sad when it gets bigger, and happy when it gets smaller.

And this KPI isn’t just an excuse for a party when you break the four-second barrier, it’s also a tool to help protect the status quo.

If the advertising team want to add more ads, or the design team wants an 8K background video, you have a solid, objective number you can use to ask a meaty question such as: “are we willing to add 700ms to our load time for an extra $40k of ad revenue per month?”

You might not get the answer you want, but you’ll know that you asked the best question you could.

I truly believe that if every company did this, the world wide web would be a faster place.

I also truly believe that we should all Rollerblade everywhere; if everyone does it, no one looks like a dork.