jeremyroman
commented
3 years ago Thanks for the feedback.
It's definitely complicated and I don't know of an easy way to resolve especially some of the misaligned incentives that exist on the web today - as you note this isn't a new problem and many of your thoughts make sense. A few thoughts:
Not making fast and smooth navigation easy may incentivize developers to make single-page web apps, or native apps, instead. If developers cannot create the fast experiences across navigation they may build SPAs which don't restrict them in this way which may be more heavy. In that case the code and a lot of content is fetched and retained in memory if the developer doesn't use significant care, and the UA can't differentiate to drop old or speculative data on the user's behalf. Or the developer may decide that they can't create good experiences on the web as easily as they can on native application platforms.
User agents are positioned to intercede on the user's behalf. If the easiest way to do prefetching and prerendering of the next page is through a platform API, the UA can make decisions that not all developers would take care to, like:
- the user's battery is low, their device is underpowered, or they're on a metered network, so prerendering is not appropriate at this time
- a limit on the number of prerendered pages, either not performing the rest or downgrading to prefetching, preconnect or DNS prefetch
- a prerendered page has already consumed a lot of CPU or network resources, so its execution will be paused
- predictions on this site have had a low success rate, so the browser should do fewer of them or step down to prefetching or preconnecting
If you're more efficient you still get big wins. Prerendering is more likely to be complete by the time the user clicks, inbound navigations that weren't predicted are faster (it's unlikely we'll reach a world where the vast majority of clicks are predicted). Inbound referrers may still care about your core web vitals (and other page experience scores).
Browser vendors might have to do considerable tuning to balance being useful enough for developers and limiting collateral impact. I don't think a full answer has been settled on in Chromium and other browsers might strike a different balance.
What discourages a site from draining a user's battery to prefetch and pre-render 10s of pages that users are unlikely to visit?
Is there a "pre-render budget" of CPU and/or battery (or a proxy for that usage) that browsers will enforce?
The incentives of today's web encourage publishers to reduce CPU consumption of pages in order to speed up load time, because faster load times means more revenue. Those same incentives also encourage development of technologies (e.g. React when used properly, AMP, etc.) that increase render speed by also reducing CPU consumption. And they make the web better for users on low-end devices who would otherwise be ignored by most publishers.
Obviously these incentives don't always work that well (e.g. any local news site covered in ads) but at least there's a reason for sites to care, albeit indirectly and imperfectly, about the impact that their sites are having on their users' batteries and electricity bills.
But if load time is further decoupled from page bandwidth and CPU impact, does it create a moral hazard where publishers will proactively suck up device horsepower and bandwidth for pages that the user is unlikely to visit? I'm thinking about cases like these:
My main concern is that this collection of features seems to intersect with self-interested human and corporate behavior in battery-draining, CPU-hogging ways that may be good for individual publishers, site owners, and browsers, but bad for users and the web overall.
Obviously, pre-rendering for pages that users are going to visit is a good thing. But imagine a world where pre-rendering is used as pervasively and wastefully as display ads. Where rushed developers, uninformed managers, and self-interested corporate actors act in predictable ways. What can go wrong in that world and how can this proposal help prevent it?
I recognize that this proposal is about the API, not the heuristics used by UAs. But given the unintended consequences of past cool tech like IFRAMEs, it'd still be good to hear about the abuse-prevention model you have in mind.