Towards a unified theory of web performance | Hacker News Reader

Towards a unified theory of web performance

infrequently.org

72 pointsM2Ys4U15 comments

While eloquently written, this article seems to make the mistake of myopically focusing on just speed in web performance, when web performance is much more than that.

Addressing the "unified theory of web performance" the article proposes:

> The mission of web performance is to expand access to information and services.

> We expand access by reducing latency and variance across all interactions in a user's session to more reliably return the system to an interactive state.

> We work to improve the tail of the distribution (P75+) because that is how we make systems accessible, reliable, and equitable.

We performance is not just about expanding access by reducing load times. It's about improving the user experience. It can be viewed as a subset of UX concerns, or a specialization of it.

Take for example Cumulative Layout Shift (CLS), a web performance metric that measures how much a page shifts as it loads. CLS is about reducing jarring user experiences by stabilizing the way content renders as it loads. Therefore fixing latency issues will not fix CLS issues, nor will fixing CLS issues allow others expanded access to information and services. Reducing layout shift will just make the user experience suck less.

It can also be about reducing overhead. Tripling my server count to improve user experience by ten percent is madness. And yet people do it all the time.

Businesses go under a lot, too. Often because nobody connects the dots. Gordon Ramsey did an entire show on the arrogance of small business owners.

It's not "madness." It depends on how much the servers cost, and how many users you have (or could have with a 10% improvement in UX).

If a 10% improvement comes from 3x the servers you are moments away from hitting the wall with Amdahl's Law. If you're hoping that 10% will increase your traffic, you aren't just going to hit that wall, you are actually driving the truck into it. That is madness. Expensive, company-ending, last-gasp madness.

It doesn't 'depend'. It's physics. "Explaining Thermodynamics and Information Theory to people praying for a miracle" is immediately after "off by one errors" on the Hardest Things list.

Sure, there's a limit on how many servers are worth purchasing. 3x servers might get us a 10% UX improvement, but that doesn't mean that 9x servers would yield a 20% improvement.

We should stop buying servers when it stops being cost effective. That may or may not be 3x the number of servers we have now. It could be we're already over provisioned, or that you should only buy 2x, or maybe you can afford 5x, or 9x, and the number may change over time as the costs of maintenance and the number/value of your users rises and falls.

> If a 10% improvement comes from 3x the servers you are moments away from hitting the wall with Amdahl's Law

If your bloated SPA loads tens of megabytes of JS and makes fans spin on all your users' computers, ... will you think about Amdahl's law, or is it fine then?

A product that is 10% better to use is a lot better... people routinely put tons of effort into much smaller amounts of benefit, as benefit is difficult to pull off; and the reality is that servers probably aren't costing the majority of your revenue.

If you have 1,000 customers paying $10 per month and you’re spending $100 a month on servers, it might easily be worth the extra $200 per month to improve performance by 10%.

CLS seems to fit fairly easily within the second goal.

Within the webperf folks at Google, we've certainly debated if CLS is a performance metric. The loose consensus is that it's not... it's a predictability and UX metric. Also "Core Web Vitals" is deliberately not scoped to just performance.

That said, it's kinda _easier_ to just simplify and say CLS is a webperf thing and CWV are webperf metrics, because going into the nuance just dilutes the entire framing.

> Also "Core Web Vitals" is deliberately not scoped to just performance.

What do you define as performance then? And how is it different from speed?

perf is all about making loading fast, scrolling & animations smooth, and interactions responsive. The classic RAIL model captures the scope of perf well. perf and speed are synonyms.

CLS is a bit of a loner as there really aren't other metrics these days that also capture non-perf signals. But again, this distinction of CLS as a non-perf metric is for webperf nerds only, IMO.

> While eloquently written, this article seems to make the mistake of myopically focusing on just speed in web performance, when web performance is much more than that.

Also funny is "Gmail loads orders of magnitude more resources and makes more requests than full page reloads" but "it's fine because we can change just a part of the page and add chat there that no one asked for"

I still remember how excited I was as a wannabe fullstack rails dev in 2012 trying explore more single-page-style UX. It felt like I was pursuing the "unified web" theory this article's title sucked me in with. "Could I make the UI less sluggish by writing a boatload more JS?" types of thoughts.

Ten years later we still have backend-rendered and frontend-rendered camps. Some of my rollercoaster ride has been filled with useless pursuits (coffeescript! I used to love how clean it was. Old style angularjs jargon like `$scope` and directives. The list goes on...). But overall I strangely think it has been worth it to keep up. The main champions have been SQL, HTML, and JS -- I use them heavily, across whatever newfangled trend I'm pursuing. I'm thankful a lot of what I learned over the years is still applicable, even as I (willingly) get yanked around by the hottest trends.

> Despite fully reloading the page, the HTML version of Gmail consumes fewer network resources (~70KiB) and takes less overall time to return to interaction.

Reminds me of the article "Browsers are pretty good at loading pages, it turns out" [1]. It's really shocking that we've got technology that from an a priori standpoint has the capability of making web browsing faster, yet consistently due to poor development practices somehow it manages to make everything worse.

[1] https://carter.sande.duodecima.technology/javascript-page-na...

Reply on news.ycombinator.com