Reboot: Performance Budget

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.