It probably won't replace Nuxt.js/Nuxt’s pre-fetching, as such websites function as SPAs, using internal JavaScript pushState navigation, which has become standard for those frameworks.

However, Next.js pre-fetching can't perform pre-rendering on hover, which can cause a noticeable lag during navigation. The native Chrome API allows not only pre-fetching, but also pre-rendering, enabling instant page navigation.

Link prefetching is generally something you would want a website to retain control over, because it can distort stats, cause resource starvation, and even (when web developers are idiots) cause things like deletions (when a clickable link has a destructive outcome).

I am reminded of the infamous time when DHH had to have it explained to him that GET requests shouldn’t have side effects, after the Rails scaffolding generated CRUD deletes on GET requests.

https://dhh.dk/arc/000454.html

Google were not doing anything wrong here, and DHH was merely trying to deflect blame for the incompetence of the Rails design.

But the fact remains, alas, that this kind of pattern of mistakes is so common, prefetching by default has risks.

Imagine mousing over a delete account button and having your browser render that page and execute JS in the background.

Like it or not, the current web standardization process requires implementations to be shipped in multiple browsers before something can enter the spec.

Internet Explorer first implemented XMLHttpRequest, and then it became a standard. Without browser makers innovating we'de be waiting a long, long time for the W3C to make any progress, if any at all.

It preloads pages on mouse hover over the a href link. On mobile there are no mouse hover events. The page can be preloaded on "touchstart" event which almost definitely results in page visit.

Not to mention laptops! Loads of people use those on battery power

Putting aside the lack of hover on mobile (there are other ways to trigger it)

It’s not clear it will waste battery on mobile… not sure if it’s still the case but mobile radios go to sleep and waking them used a non-trivial amount of energy so preloading a page was more efficient than let the radio go to sleep and then waking it

Need someone who’s more informed than I am to review wether that’s still the case

The point of this proposal is to bring this feature under the control of the browser, which is probably better placed to decide when preloading/prerendering should happen. It's already possible to do something very similar using JS, but it's difficult to control globally when that happens across different sites. Whereas when this feature is built into the browser, then the browser can automatically disable prerendering when the user (for example) has low battery, or is on a metered internet connection, or if the user simply doesn't want prerendering to happen at all.

So in theory, this should actually reduce bandwidth/battery wastage, by giving more control to the browser and user, rather than individual websites.

Those aren’t mutually exclusive goals. You can serve efficient pages AND enable pre-fetch/pre-render. Let’s strive for sub-50ms load times

“Just” is doing a lot of heavy lifting there. There’s a lot that has to go on between the backend and frontend to make modern websites with all their dynamic moving pieces, tons of video/imagery, and heavy marketing/analytics scripts run on a single thread (yes I’m aware things can load/run on other threads but the main thread is the bottleneck). Browsers are just guessing how it will all come together on every page load using heuristics to orchestrate downloading and running all the resources. Often those heuristics are wrong, but they’re the best you can get when you have such an open ended thing as the web and all the legacy it carries with it

There’s an entire field called web performance engineering, with web performance engineers as a title at many tech companies, because shaving milliseconds here and there is both very difficult but easily pays those salaries at scale

Theres only so much efficiency you can squeeze out though if, say, you're using AWS Lambda. I can see this helping mitigate those cold start times.

You can't avoid sending the user photos in a news article, for example. So the best you can do is start fetching/rendering the page 200ms early.

Hasn't been implemented yet, but Mozilla supports this proposal and plans to implement it:

https://bugzilla.mozilla.org/show_bug.cgi?id=1969396

Definitely a balancing act where you consider how much work you might trigger.

But I can think of a few places I would use this for quality of life type enhancements that are for specific clients and etc.

I've seen some sites, like Amazon, calculate the probability of a user clicking a link and preload the page. This is called predictive preloading (similar to speculative fetching). It means they load or prepare certain pages or assets before you actually click, based on what you're most likely to do next.

What I like about this is that it's not a guess like the browser does, it's based on probability and real user behaviour. The downside is the implementation cost.

Just wondering if this is something you do too.

Then it’s a badly designed website, GET requests (and arguably the JS delivered with a GET-requested HTMl page) should be side-effect free. Side effects should come from explicit user interaction.

It does, but currently is supported only in Chromium-based browsers. Also with pre-rendering on hover pages are displayed instantly unlike with instant.page where rendering happens on link click which might take a few hundred ms before displaying the page.

Update: Actually instant.page also uses Speculation Rules API where it's supported

Fast on desktop, decent on mid-tier mobile, and slow on low-end devices.

It is less about performance issues of loading megabytes on the browser (which is also an issue). It is about those cases where a fetch request may take a noticable amount of time just because of server distance, maybe the server needs to perform some work (ssr) to create the page (sometimes from data fetched from an external api).

If you have a desktop app it will also have to do the same work by fetching all the data it needs from the server, and it might sometimes cache some of the data locally (like user profile etc...). This allows the developers to load the data on user intent(hover, and some other configurable logic) instead of when application is loaded(slow preload), or when the user clicks (slow response).

Even if the the target page is 1byte, the network latency alone makes things feel slugish. This allows low effort fast ui with good opinionated api.

One of the reasons I can identify svelte sites within 5 seconds of visiting a page, is because they preload on hover, and navigating between pages feels instant. This is great and fighting against it seems unreasonable.

But I agree that in other cases where megabytes of data needs to be fetched upon navigating, using these features will probably cause more harm then good, unless applied with additional intelligent logic (if these features allow such extension).

Edit: i addressed preloading, regarding pretending its a whole new set of issues which i am less experienced with. Making web apps became easier but unfortunately them having slow rendering times and other issues.. well is a case of unmitigated tech debt that comes from making web application building more accessible.

It depends on how heavy the assets are and the user's connection.

On the right site it can make navigation feel instant

Man, the amount of headaches turbo give me... I have ended up with apps polluted with "data-turbo=false" for this exact same reason... But I also admit that when it works, it's a really nice thing to have

TurboLinks only replaces the <body> so you can put any scripts you'd like loaded exactly once into the <head> tag. You can use <script async> to keep it from blocking.

maybe its the fact that its really easy adding something like this, and this (I think) or something which basically acomplishes the same thing (but in a better way?) are used by some major meta frameworks like nextJS etc.

I guess it has limited applicability but maybe its the small little gains that add victories. I really may be going on in a tangent but I always used to think that hardware is boring / there aren't too many optimizations its all transistors with and,or,not but then.. I read about all the crazy stuff like L1 cache and the marvel machinery that is known as computers. It blew my mind into shredders. Compilers are some madman's work too, the amount of optimization is just bonkers just for tiny performances but those tiny performance boosts in the whole stack makes everything run so fast. Its so cool.

Part of the design of the feature is that the website doesn't have to specify "on hover" or "on focus", but instead they can just write "eagerness: moderate" (or "conservative", or "eager") and let the browser decide what the exact triggers are. If it turns out that keyboard focus is a useful predictor of whether a link is likely to be clicked, then browsers can add that as a trigger at one of the indicator levels, and websites will automatically get the new behaviour "for free".

Currently, "eagerness: conservative" activates on mouse/pointer down (as opposed to mouse/pointer up, which is when navigation normally happens), which will work for mobile devices as well. And "eagerness: moderate" includes the more conservative triggers, which means that even on devices with no hover functionality, prerendering can still kick in slightly before the navigation occurs.

Yes, but it's in concept always been true that they could get page views that wouldn't be viewed, whether due to bot scraping or even sometimes where a human clicks and then just... doesn't read it.

Analytics can detect prerendered pages and choose how they report them - GA ignores them I believe

In practice, this is almost entirely going to be used for internal links within a domain - you are not going to want to prerender domains you don't control, because you can't be sure they'll be prerender-safe. And I suspect most internal navigation will be obvious to the user - it's typically clear when I'm clicking links in a nav menu, or different product pages on a shopping site. So I suspect your first issue will not come up in practice - users will typically not need to check the sorts of links that will be prerendered.

Tracking is a legitimate concern, but quite frankly that's already happening, and at a much finer, more granular level than anything this feature can provide. Theoretically, this gives the possibility to add slightly more tracking for users that disable JS, but given the small proportion of such users, and the technical hoops you'd need to jump through to get useful tracking out of this, it's almost certainly not worth it.