Notification of canceled prerendering?

[domenic]

Consider a page /A which thinks it is very likely the user will navigate to /B. The page wants to do as much as possible to ensure navigations to /B is fast.

One strategy a page might want is something like:

• Try to prerender /B. If this fails, or the prerendered browsing context is discarded...
• Try to prefetch /B with subresources. If this fails, or the prefetched resources are discarded, then...
• Try to prefetch /B (by itself). If this fails, or the prefetched document is discarded, then...
• Try to preload some critical subresources of /B.

Currently we have no mechanism to tell if a pre* fails or is discarded. So this is not really possible.

Should it be possible? If so, should it be via some mechanism that allows programmatic fallback? Or should it be more automatic via the browser?

[jeremyroman]

My gut is that we should resist an explicit API, because it will give direct signal about what prefetches/prerenders are occurring (which might be leaky about that) and because it might create an incentive for developers to repeatedly retry in order to get as much of the device's scarce resources for themselves.

I do think the browser should fallback internally. Ideally by default (prerender -> prefetch-with-subresources -> prefetch -> preconnect -> dns-prefetch), unless we have a reason not to.

[rossrobino]

Having this fallback would be helpful since prerendering can be unsuccessful in browsers that still support the API. This often occurs without the user knowing it due to an extension, or simply if a user changes their browser preferences.

Anecdotally, I've run into this case twice:

• Chrome extensions - My work computer uses an extension that cannot be disabled in Edge, which blocks prerendering.
• Testing in Arc (thanks @tunetheweb) - Arc browser has uBlock origin on by default which turns off preloading by default. After enabling, prefetching works, but prerendering does not.

In both of these cases, HTMLScriptElement.supports("speculationrules") === true but the prerender fails and nothing is prefetched.

Blog post on web.dev with more details from @tunetheweb

In these cases, the best fallback I have found is to also add <link rel="prefetch"> in addition to the speculation rules script. This covers browsers that don't support the API, as well as if the prerender fails. See implementation

I've also found adding the url to both prefetch and prerender works as well.

{
    prerender: [
        {
            source: "list",
            urls: [url],
        },
    ],
    prefetch: [
        {
            source: "list",
            urls: [url],
        },
    ],
}

I think it's safe to assume that prefetching is desired on a failed attempt to prerender. I like @domenic's strategy outlined above. Having it be automatic would simplify the fallback instead of detecting it with an API.

---

Edit:

If this fallback isn't provided, what is the best way to fallback to prefetch? Is adding <link rel="prefetch"> or an additional prefetch value in the Speculation Rules script the recommended approach?

[domenic]

Thanks for this comment! At a minimum, it'll help us prioritize working on the automatic fallback, which I think is a no-brainer win.

I'm also continuing to feel that a client-side detection API would be helpful, and we've been having some ongoing discussions about that. But as @jeremyroman mentions, it's tricky since it can encourage bad behaviors and can be tricky for privacy reasons with e.g. cross-site subresources on the prerendered page.

If this fallback isn't provided, what is the best way to fallback to prefetch? Is adding <link rel="prefetch"> or an additional prefetch value in the Speculation Rules script the recommended approach?

Additional prefetch value in speculation rules is the recommended approach. It has the advantages over <link rel=prefetch> listed in https://developer.mozilla.org/en-US/docs/Web/API/Speculation_Rules_API#using_prefetching .

[rossrobino]

Appreciate it, thanks for the guidance on the fallback!