Infrequently Noted

Alex Russell on browsers, standards, and the process of progress.

Comments for Can You Afford It?: Real-world Web Performance Budgets

Hi Riya,

Lighthouse was mentioned in the list of available tools as "Scripted Lighthouse". Note that WPT can now also run Lighthouse audits and, importantly, can do so from real hardware.

Regards

by alex at
Well-informed & Comprehensive information But I would also like to add "Google LightHouse" tool in your list.

Thanks

@Andrei Rînea As always it depends. WebAssembly was build with performance in mind and bytecode can be smaller than minified JS. It is also faster to parse (because it is stack machine and can be parse during load). Unfortunately WebAssembly can't do much on its own and require JS bindings, that can take up much space. It will provide performance gains, but not always transfer size gains.
by Kukuluops at
That's 130–170KB of JS decompressed/unzipped, correct?
by Tyler Reitz at

Hey Tyler,

130-170KB is the size the the wire (hopefully zipped/compressed). This gives us a pretty large payload budget (nearly 1MB) of uncompressed critical-path content.

Regards

by alex at
Strange that Angular 4/5 doesn't fall in your list of recommended frameworks for real world performance. Would be good to know why.
by Tarun Elankath at
Hey Alex,

I'm curious about the suggested network constraints:

The default global baseline is a ~$200 Android device on a 400Kbps link with a 400ms round-trip-time (“RTT”)

This seems different than both:

The Google PWA Checklist, which merely suggests using a "simulated 3g network". The Chrome browser itself seems to have recently simplified throttling options – now only displaying "Fast" and "Slow" 3g as defaults. It's unclear what conditions these emulate:

https://developers.google.com/web/progressive-web-apps/checklist#first-load-very-fast-even-on-3g

Lighthouse and WPT:

https://github.com/GoogleChrome/lighthouse/blob/bedb9a153eef670d1fc6c22aaac5ef0b243a1607/docs/throttling.md#the-3g-network-throttling-preset

How should teams approach choosing their network constraints?

by John at
Hi Alex,

With HTTP2, do you prefer to keep all assets bundled as one?

Do you prefer to add realfile of zipped asset (app.js.gz) ?

Thanks for you great article, 130KB really great hint for faster load :D

by Naura at
Alex,

GREAT post! I love how thorough you were.

I'm even including it in my newsletter for tomorrow morning as a highlighted post!

Again, great work!

JD

Performance Budget is also a thing we encourage our clients to calculate at Dareboost (we wrote about it too here), at Dareboost. Performance, as any QA component, is a mean to an end and should be controlled.

Unfortunately, performance, and more generally quality Analysis, are not mastered by the vast majority of web actors. The subject need a long and slow phase of acculturation to be fully mastered and that phase can't start with some "quick wins" to wrap a company mindset around web performance avantages.

by Boris at
Because we shouldn’t need to ever go to the network to get our app’s UI booted once we’ve visited it the first time. Service Workers and “offline first” architectures enables us to put interactive pixels on screen without ever touching the network.

Your examples gave an accounting for framework + app, but I didn't see any mention of how you accounted for the site of all this extra JavaScript that you need to load on the first page load in order to make repeat page loads faster. That is going to eat into that 130KB - 170KB budget even further.

Possibly a bit off-topic but will WebAssembly help some of these issues?
Great tips, thanks for reminding everyone how important speed is, and how easy it is to become bloated.

Can I suggest another speed monitoring service in your list? I created MachMetrics (https://www.machmetrics.com/) over a year ago and we're pretty on par with the others. Am always looking for feedback.