Merge prefetch and prerender?

[igrigorik]

• Both are used to fetch resources for next navigation - i.e. requests persist across page navigations and are not cancelled as part of onunload.
• Prefetch (currently) allows fetch of any content-type, and does not process the response.
• Prerender is (currently) meant for HTML docs and processes the response.

Arguably, whether or not the response is "processed" is a decision that should be left to the user-agent. In fact, prerender already exhibits this behavior, since user agent is allowed to perform partial processing (e.g. download the page and perform shallow parse for critical resources, etc). By extending the same logic, its not unreasonable to "prerender" an image by decoding it, or preparse a CSS/JS response.

As a result, I think we could collapse prefetch and prerender into one hint:

<link rel="prerender" href="/next/page.html" type="text/html">
<link rel="prerender" href="/logic.js" type="text/javascript">
<link rel="prerender" href="/product.jpg" type="image/jpeg">

The type attribute is used to set the relative request priority, and the decision how/if the resource is processed is deferred to the UA - e.g. a simple strategy is to only perform the fetch for non-HTML resources, which is the current prefetch behavior.

P.S. Perhaps the "prerender" name is not the best choice for describing decoding/preparsing and other steps for non-HTML resources. Perhaps, "preprocess" is a better choice? Then again, the name doesn't bother me that much.

[willchan]

Processing is a bit vague. Prerender brings up an inactive browsing context that only activates when the navigation actually occurs. Prefetch doesn't do any processing. It's also unspecified which browsing context it belongs to and whether or not it should be transferred to a new browsing context upon navigation.

[igrigorik]

@willchan the distinction between browsing contexts seems like an implementation detail that's best deferred to the UA? To an outside observer, prerender simply delivers an "instant page load" when they trigger the navigation -- how the plumbing is done under the hood is not important to the site developer or the user.

That said, what is important to the site developer is to know that prefetch requests initiated on the previous page are not cancelled and are properly reused when the navigation occurs - e.g. if I started prefetching "photo.jpg" and then a navigation is triggered, the "photo.jpg" request is allowed to continue and the prefetch response is returned to any requests for that resource on the target page.

(which is how Chrome handles this: https://crbug.com/286186)

[willchan]

I'm mostly trying to reconcile these new attributes with what existing specs say. For example, the HTML Living Standard says that when aborting a document load:

Cancel any instances of the fetch algorithm in the context of this Document, discarding any tasks queued for them, and discarding any further data received from the network for them. If this resulted in any instances of the fetch algorithm being canceled or any queued tasks or any network data getting discarded, then set the Document's salvageable state to false.

And notably, it also says that navigation across documents aborts the document load.

Also, specifying the context of the resource fetch is important, because it affects how the resource fetch relates to ResourceTiming.

[igrigorik]

Right, great points. We would need to amend some of that language. Canceling prefetch and prerender requests across navigations defeats the purpose of those mechanisms. Also, its worth noting that these behaviors are not "new", both prefetch and prerender exist today and implement this logic, so... this is more of a cleanup to conform with what's actually deployed and working.

• Prefetch & prerender should be allowed to persist across navigations.
• Preconnects should be allowed to persist across navigations - e.g. preconnect for a redirect target.
• Preloads should be cancelled, since they are signaling resources for current browsing context.

/cc @marcoscaceres @slightlyoff

[willchan]

Yep. I'm probably just getting ahead of myself. Things need to be more fully specified eventually to nail down these edge cases and make sure the various specs complement one another appropriately, but there's no hurry. Your intent here is clear to me, and as we've discussed before, I basically agree with them.

[marcoscaceres]

@igrigorik what you describe in your comment above makes sense (with regards to prefetch and prerender persisting across navigations). It might also make sense to merge the prefetch and prerender - though to pre-process/parse resources (particularly JS) out of context might not make much sense.

[igrigorik]

First attempt at merging the two: https://igrigorik.github.io/resource-hints/#prerender - WDYT?

[yoavweiss]

Slight concern about this merge: Are there any valid use-cases for preloading an HTML page without fetching all of its resources? If so, we're killing off that use-case, since prerender would potentially mean that the browser may also fetch all of its sub-resources.

A use case I can think of is when a user has multiple links in the current page, where he's likely to go to one of them, but the author is not sure which one. If these pages are relatively small, but resource heavy, the author may want to tell the browser "prefetch these next HTMLs, but don't download their resources since the user may go to any of them".

Are there any usage patterns in the wild where authors have picked "prefetch" over "prerender" for HTML pages? Maybe we can conclude from that regarding the importance (or lack of it) of this use case.

[igrigorik]

A use case I can think of is when a user has multiple links in the current page, where he's likely to go to one of them, but the author is not sure which one. If these pages are relatively small, but resource heavy, the author may want to tell the browser "prefetch these next HTMLs, but don't download their resources since the user may go to any of them".

What if I'm browsing your site on my 8-core machine with oodles of RAM, GPU memory, and a fiber connection? It's completely reasonable to let the UA prerender multiple pages, and fetch all of its subresources in that situation. On the other hand, if I'm on a resource-constrained handset that's roaming and about to run out of battery, the UA may decide to downgrade the hints to preconnects only... What I'm getting at is that given the wide variety of hardware + user preferences + connectivity profiles, the decision as to how much work is performed is best left to the user agent. Ideally, it goes all the way, but if that's not possible, then it should do as much as it can.

If you specify multiple prerender targets, the UA can balance that and decide to only go as far as prefetch for each of them vs. a single prerender target where it may also fetch the subresources, etc.

Are there any usage patterns in the wild where authors have picked "prefetch" over "prerender" for HTML pages? Maybe we can conclude from that regarding the importance (or lack of it) of this use case.

Given the current (sorry) state of these hints (inconsistent implementation, missing support, etc), I wouldn't trust any of the existing adoption data.

[yoavweiss]

I agree that the UA should have liberty here, but it'd be cool if we could let authors provide it with some sort of indication regarding the probability of the user going to followup pages. prefetch vs. prerender provided some hint in that spirit.

I guess we can merge them, and then see how to provide further probability hints later on, if necessary.

[igrigorik]

Right, that seems reasonable.

There are two inputs here: user context (available resources, etc), and probability of using that resource. The UA knows the former, the developer can provide the latter, and by combining the two the UA can decide whether and how far it should proceed with speculative optimization...

[igrigorik]

Closing this. Let's continue the priority discussion in #17.