Never-Slow Mode a.k.a. Slightly-Fast Mode

A cynical part of me notes that adding more complexity to browsers just makes Chrome monoculture easier: I have no doubt that Google can win any war of "throw developers at it". But it feels like they're building a complexity debt nightmare that we'll all suffer from.

Edit: I guess the other and more direct angle for why Google would push this is that they can give "fast" sites a ranking boost in search, i.e. dictate what web pages do via soft power to make their job easier.

In any case, it is impossible to prove that your JS code will not somehow exceed these limits on a rarely exercised execution path. So I recommend turning this on in production as soon as the halting problem is solved.

Also, if scrolling increases the budget, doesn't that penalize sites for being loaded in larger browser windows as the user has to scroll less?

This isn't really what people like me meant when we said we wanted Google to use performance metrics in their ranking. We wanted Google to come up with its own internal metrics, not standardize them across the entire web. Because performance isn't standard, it's extremely context-specific, and it's important that sites like search engines and browsers be able to iterate quickly on their metrics and to change them depending on what the ecosystem currently looks like.

I genuinely just don't understand what value standardization has here other than to make the system easier to game and less flexible in the future.

What positive, consumer-friendly, non-scammy things are possible for us to do with a universally standardized set of performance criteria that we couldn't do with privately maintained, non-standardized sets of criteria?

Other big tech companies like Facebook or Netflix don't follow Google's approach, because most products are sprawling, and built by many teams and many engineers. Keeping a small, tight, codebase under those conditions doesn't work.

Contrast Never Slow mode with what the React folk are doing with React Fiber. They have rewritten their engine to allow JS execution that doesn't block the main thread. This is much more pragmatic than setting budgets and simply telling devs to try harder.

Too many people shovel on slow JavaScript libraries and make the user experience worse. Speed is a tradregy of the commons issue - it's time serious action was taken to resolve it.

I could imagine an <iframe allow-slow-performance-shares=33%>, and leaving the iframe to figure out how to subdivide this among itself and its children. (And something similar for the main document.)

Deploying this will be hard, since the slowest devices also tend to run outdated browsers (and thus won’t enforce limits anytime soon.)

No line of JavaScript may execute more than 200 milliseconds after the last user touch/tap.

That would still let video sites play videos, but everything else would have to be 'ready to view' within 200ms. Let the developer decide if they want to achieve that by making resources smaller, having fewer resources, getting rid of js frameworks, etc.

Sites which need more time could demand the user hold a finger on the screen while they load up their heavy frameworks, but that would be a clear "we are slow" indicator the site would want to avoid.