In which I do a systemic analysis of the past performance to define the practical budget for the reboot.

Reboot: Performance Budget

1055 words about creative — 09:00 · 1st Aug 2020

When I looked at my strategy for performance, the question I asked myself was this:

“How long will a person have to wait before they can perceive and interact with my website?”

With that question leading the way and my goal of wanting this reboot to be faster than my previous website, I’m now going to do a systemic analysis of the past performance so that I can define the practical budget for the future performance.

I’m looking at the top-visited pages again to determine what to test.

I’m excluding A Scary, Hairy Beard Story because, despite its popularity, at 5,400 words it’s longer than most entries which are between 500-1,000 words.

Using Google Lighthouse to run automated tests I’m specifically looking at First Contentful Paint (FCP), Time to Interactive (TTI), and the total Kilobytes (KB) transferred to establish a baseline average.

Page FCP TTI KB, Total
/ 0.9 s 2.9 s 424 KB
/blog/{title} (average from 4 entries) 1.1 s 2.9 s 445 KB
/blog/ 1 s 2.9 s 388 KB
/about/ 1.3 s 2.8 s 441 KB
/topics/ 1.6 s 3.3 s 416 KB
/archive/ 1.4 s 2.9 s 418 KB

All tests were run under the following simulated circumstances: Nexus 5X, 150 ms TCP RTT, 1,638.4 Kbps throughput. CPU throttled, 4x slowdown.

Calculating the mean (average) for each of these gives me 1.2 seconds to the First contentful paint, 3.0 seconds to Time to interactive, and 422 KB total transferred.

I might return to individual pages and their performance, as a secondary budget, when I continue working on them.

And that, in a simplified manner, is my baseline.

I could be using Google Lighthouse scores themselves but I’m wary of too many abstractions. Also, my previous website scores 0.98 on Performance so according to Google I’m past the point of diminishing returns.

[…] Around a score of 0.96 is the “point of diminishing returns” as above it, the curve pulls away, requiring increasingly more metric improvement to improve an already high score. How Lighthouse calculates your overall Performance score

As their Performance score is a weighted average of the metric scores, which in turn are calculated under the hood, I have no access to the actual metrics being compared against.

Google Lighthouse also changes their weightings from each major version to another, and whilst I’m sure it’s based on sound, not at all biased (cough cough), research, I’m better off knowing the raw metrics.

Anyway, baseline: 1.2 s FCP, 3.0 s TTI, and 422 KB.

3 seconds being the closest to answering my, “How long will a person have to wait before they can perceive and interact with my website?”

Now, using the Weber–Fechner law, and their research and findings on just noticeable difference, i.e., “How much does something have to change for the difference to be noticeable?” as a guide, gives me a range of 7-18%, so let’s round this up to 20%.

So, for most people to notice a difference, my reboot needs to be 20% faster.

Let’s take the baseline numbers and figure out what the reboot numbers should be. For extra credit we’ll also compare both to the “average” webpage:

Editor’s note: There’s no such thing as extra credit on your personal blog

Metric Baseline Reboot budget Average1
First contentful paint (FCP) 1.2 s 1.0 s 5.6 s
Time to interactive (TTI) 3.0 s 2.4 s 9.3 s
Kilobytes, total 422 KB 338 KB 2,059 KB

At 2.4 seconds, my reboot needs to be 0.6 seconds faster on Time to interact for people to notice it. Which gives me a total budget of 338 KB.

Now, I’m almost done.

It’s worth remembering that not all resources are treated equally—much like people in the real world—and different technologies affect performance differently.

JavaScript, for example, is slow to process client-side.

So, to finally get a bit-by-bit budget, let’s look at each resource type and see what’s contributing to the 422 KB baseline because understanding this, will inform where I can spend more and where I need to cut back.

Image Font Script Document Stylesheet KB, Total
/ 268 KB 74 KB 48 KB 11 KB 6 KB 424 KB
/blog/{title} (average from 4 entries) 253 KB 90 KB 48 KB 16 KB 6 KB 445 KB
/blog/ 248 KB 36 KB 48 KB 11 KB 6 KB 388 KB
/about/ 248 KB 90 KB 48 KB 12 KB 6 KB 441 KB
/topics/ 248 KB 36 KB 40 KB 48 KB 6 KB 416 KB
/archive/ 268 KB 63 KB 48 KB 15 KB 6 KB 418 KB

Good, now let’s calculate the mean (average) for each of these resource types, the means becomes the baseline numbers and I then figure out what the reboot numbers should be.

For another extra credit I’ll also compare both to the “average” webpage’s resource types:

Editor’s note: See previous note. Dickhead.

Resource type Baseline Reboot budget Average2
Image bytes 256 KB 268 KB 983 KB
Font bytes 65 KB 20 KB 129 KB
Script bytes 47 KB 20 KB 453 KB
Document bytes 19 KB 20 KB 26 KB
Stylesheet bytes 6 KB 10 KB 72 KB
Total kilobytes 422 KB 338 KB 2,059 KB

It is often said, that the average webpage is as big as the classic computer game Doom.

However, unlike the average webpage, Doom was a pioneering first-person shooter, which introduced 3D graphics, third-dimension spatiality, networked multiplayer gameplay, and support for player-created modifications.

Is my webpage pioneering the website industry?

It isn’t.

Probably not even a little.

Which is why 338 KB is my budget, not 2,059 KB.

Split by each resource type, we finally get to the end—this entry got a lot longer than I anticipated.

This is my performance budget.json for the reboot, whereby a person will have to wait 2.4 seconds before they can perceive and interact with my website:

[{"resourceSizes":[
  {"resourceType":"image","budget":268},
  {"resourceType":"font","budget":20},
  {"resourceType":"script","budget":20},
  {"resourceType":"document","budget":20},
  {"resourceType":"stylesheet","budget":10}
]}]

To stay within that performance budget I’ll then have to do one or more of the following things:

  1. Optimise an existing feature or asset on the page.
  2. Remove an existing feature or asset from the page.
  3. Don’t add the new feature or asset.

Or, at least, that’s the plan.

Wish me luck.

  1. As measured on HTTP Archive on 31st July 2020, https://httparchive.org/reports/loading-speed 

  2. As measured on HTTP Archive on 31st July 2020, https://httparchive.org/reports/page-weight 


You’ve just read Reboot: Performance Budget .

In which, 2 months ago, I wrote 1055 words about creative and I covered topics, such as: web design, behind the scenes, data, and performance.