This seems a bit like a complication that browsers shouldn't be handling? Like really, do we need this feature baked into the web forever, just to make it easier for websites to audit their performance?
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.
I think the real motivation is to allow Google to use guaranteed never-slowness as an unspoofable ranking signal, essentially creating an alternative to AMP that doesn't require special tags or libraries.
Yea, that's kind of what I meant to say, although I wasn't thinking about AMP. Can Google really not use the vast amounts of data it ingests to deduce which sites have bad user experiences and are slow, though? Shouldn't that be their core competency?
Yes, Google's crawler already calculates page speed yet they've observed that few popular sites are fast. Another aspect of AMP and NSM that I didn't mention is that they are binary; this prevents sites from adding just a little more bloat and then just a a little more after that until they're quite slow.
> they can give "fast" sites a ranking boost in search
They can already do this though, right? They can even use the same criteria.
I guess the difference is they wouldn't have to measure it themselves and they could just trust the browser to enforce it. But they already have to execute the web page to get the indexed content, and the limits they're imposing here seem to be unworkable for most SPA's, since the document-level restrictions around things like images break down if you're going a long time without reloading the page. So it's only indexed content that would ever enable this in the first place.
The only benefit I can see is that it would allow them to bake the UI into the browser, which would make it more obvious to users. And that's great, except for the tiny problem that performance isn't binary and different browsers and environments will want to have different standards.
None of the restrictions here apply to service workers. Why not? Why shouldn't browsers like Opera Mini be able to apply a different list of restrictions that include service workers? And if we're OK with browsers applying extra restrictions, than what's the value of standardization?
This does not remotely belong in a HTTP header. DevTools, CI is more like it.
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.
Yeah, I have a hard time seeing what value this feature directly provides to the end user. The changes that a web site would have to make to make it work are all well and good -- but those changes are just as valuable if never-slow mode isn't enabled. The only effect that turning this flag on has is to make the web site malfunction if it tries to do something "slow"!
Of course, by careful engineering and restrictions (e.g. straight up no dynamic memory allocation). On systems where you can understand and measure the entire execution path from electrical trigger to response. And in any case, they don't wire in blow-up switches when the timing fails.
On the other hand, we have the modern frontend project with its 300 nodes in the dependency tree, of which a handful are written by whoever will be turning this on. Are you sure your i18n library isn't lazy-loading translations and you blow the budget once someone selects not-English?
Perhaps the halting problem being solved would imply that a time machine, if possible, would be solved as well? EG.. Imagine a program that halts if a program that iterates over every possible combination of a machines includes a time machine. Then devise a program that halts if the first step of building a time machine is to get a thimble, etc. Do some sort of binary search over the steps of building a time machine by constructing halting problems. What I'm getting at is that if the halting problem was solvable perhaps someone would travel back in time and tell us the solution to the halting problem. Or perhaps they wouldn't, but I wonder if they could.
What's the likelihood that a mode like this will lead to sites starting to change their design to encourage more scrolling/tapping/clicking, simply so they get a larger resource budget? "Oh we could just show this information, but if we put it behind a 'tap here to see more' link we'll be able to load 10 more images!"
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?
Why have a standardized definition of what a "fast" website is, when Google can just impose and publish its own standards for Search, or even implement its own nontransparent standards in the back end if its worried about metrics becoming targets? I don't mean that as a sarcastic question, I don't see any problem at all with a private approach.
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?
The austerity approach to page performance works for Google because they control their whole stack, they have world class devs to can devote time to fine tuning products, and their bread and butter is in small, focused tools (search is an input and a list).
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.
It’s unfortunate that, under this proposal, one may end up splitting an application into multiple iframes to get “enough” budget (or, somewhat more nasty, an embedded iframe could decide to add a second internal iframe).
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.)
I think such featurse should be instead configurable only by the user, per URL, with customizable thresholds, and that no reporting should be implemented.
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.
> No line of JavaScript may execute more than 200 milliseconds after the last user touch/tap.
This is how Opera Mini "implements" JavaScript. The Opera Mini server will run whatever JavaScript code there is in the page for ~2 seconds. Whatever can be seen on the screen at that point is sent to the Opera Mini client.
It works good enough for things like SPAs and "click here to show more".
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.