Wonder if this is will replace how nextjs and nuxt do optimistic pre-fetching when users hover on links.

Also brings up the questions:

- should browser do this by default?

- if yes, would that result in too many necessary requests (more $$)?

Either way, good to know.

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.