Should removed/modified speculation rules cancel existing prefetch/prerender?

[jeremyroman]

It seems clear that it should encourage UAs not to start new speculations (with some latency). It also seems like a signal that a prefetch/prerender is less likely to remain a good use of resources, though an application which added/removed rule sets on hover or similar (or added/removed links if we had document rules) might cause this to thrash.

Some obvious paths here:

1. Browsers should generally keep them around (they've already done at least some of the work) and use them.
2. Browsers should generally discard them.
3. Browsers should generally keep them around but not use/activate them unless rules are restored.
4. Browsers should generally keep them around for some amount of time and discard them thereafter. (On the prefetch side at least this is somewhat redundant with the limited lifetime of prefetches anyhow.)

Spec-wise we could leave this open-ended, but it would be good to give some guidance at a minimum -- and we're going to have to make some kind of concrete decision for Chrome, at least. In practice I'm leaning toward something like 4.

[jeremyroman]

@clqsin45 This seems somewhat related to https://crbug.com/1169594; has the prerendering team done any other thinking about the cancellation by trigger case?

@domenic @noamr for general wisdom

[noamr]

I believe we should spell out that removing a speculation rule should discard its prerenders, and recreating it should potentially retrigger the prerender. It would be the only way for devs to re-trigger/abort a prerender

[domenic]

It feels wasteful to me to discard any work here. So (2) feels unfortunate. But I'm unsure about circumstances under which devs might want to abort or re-trigger a prerender; if such circumstances exist, then maybe (2) is necessary as @noamr indicates.

Otherwise I would lean toward (1) or (4) since (3) is a bit complex and even harder to imagine use cases for.

[noamr]

It feels wasteful to me to discard any work here. So (2) feels unfortunate. But I'm unsure about circumstances under which devs might want to abort or re-trigger a prerender; if such circumstances exist, then maybe (2) is necessary as @noamr indicates.

Otherwise I would lean toward (1) or (4) since (3) is a bit complex and even harder to imagine use cases for.

It's unfortunate but also deliberate and probably rare for webdevs to remove an existing speculationrules, unless they wanted something like this to happen...

[jeremyroman]

I'm picturing what a library that acts on hover might do (though in practice instant.page and QuickLink both never remove the hints they add, as far as I can tell), and what the effect of future document rules ought to be for links that appear in hover cards etc (though we can just specify them to have implicit or explicit hysteresis at the link-matching level).

I was curious what Chromium does for \. Curiously \ cancels when removed, \ ignores removal, and \ ignores it except to unblock loading, so kinda all over the map.

[nhiroki]

(4) seems reasonable in terms of resource consumption and reusability on retrigger. In addition to the timeout, we may want to preferentially drop it when the number of concurrent prerendering reaches the limit. In Chromium currently the limit is 1 but we have a plan to expand it.

[jeremyroman]

I actually think I find @noamr's argument that developers probably ought to have a way to remove it convincing and doing so by default probably does make sense, close to immediately (I think I'll probably just queue a task). Developers could add hysteresis in their library code (delaying the removal of a rule set) and we could consider adding a developer-specified delay either generally or for document rules in particular in the future, as a separate thought to consider.

[Clqsin45]

I was thinking about the cancellation case, so a SpeculationHost knows all prerenders that it started (in preparation for the cancellation happening). But I didn't dig it too deep.

I think we agree that developers should be able to manipulate prerendered pages, which means they should be able to discard and update the pages, and we want to know how we can save more resources, as prerendering can be expensive.

I guess my my first question might be: why do developers want to discard a prerendered page? would they prefer updating(modifying) to canceling? I think developers may want to "update" the rule rather than to "delete" an existing one(Though we may discard an existing one and create a now one :) ), unless the prerendered page is affecting the primary page (which we'd like to avoid). It seems reasonable to always have one page prerendered. And as some resources have been loaded, it seems we can retain them for a while, and the site doesn't seem to lose anything if we do that. (I'm thinking about BFCache; it seems developers are happy with the cached pages because the pages lives longer)

What's the difference between "updating" and "canceling and restarting"? I think updating a prerendered page can save more resources. When prerendering a page, we speculatively pay some price in terms of:

1. client resources: a new renderer process, some allocated frames, etc.
2. network resources: these seems unavoidable , but I guess some prerendered results can be cached?
3. cost on the server side: As the page proactively updates the rule, it should agree that the cost can be wasted. If we only navigate an existing prerendered page to the newly updated url, instead of discarding everything we prepared and starting over, it would save 1.

So then,

• If sites believe that the user is more likely to visit a.com/b than a.com/a, and want to discard a, they can update the rule. we can keep the old prerender alive for a while, waiting for a.com/b to be specified.
• If sites think the user may also want to visit a.com/b, they can append a.com/b to the url list.
• If sites only want to discard the prerendered result for some reasons, they can remove the rules, showing their intentions explicitly.

[noamr]

I guess my my first question might be: why do developers want to discard a prerendered page?

If they believe the content of the prerendered page has become obselete and they want to make sure a fresh version is fetched and that the prerendered page is not used.

• If sites think the user may also want to visit a.com/b, they can append a.com/b to the url list.
• If sites only want to discard the prerendered result for some reasons, they can remove the rules, showing their intentions explicitly.

I think this adds unnecessary complexity. If the web developer wants to prerender a.com/b they can add it to the list, and remove a.com/a when they feel it's unnecessary or when it's obselete, either immediately or later.

Adding meaning to what "updating a speculation rule" means and making those rules hold some kind of mutable state is a second degree of heuristics and I believe web devs would have a hard time following it.

[domenic]

Where did we land on this, in both spec and implementation, and for both prefetch and prerender?

[jeremyroman]

The model I've been working with is basically: whenever speculation is considered (which always includes after rule sets are modified), if a speculation was started which no longer matches any candidate (i.e., any rule) then it is cancelled and may not be used to satisfy a navigation. However, if it was within the same partition then this doesn't prevent any changes to the HTTP cache from being visible, just that the prefetch won't get special behavior (like ignoring certain caching headers for an amount of time) and the prerender browsing context will be discarded. This means that, assuming the page has suitable cache control headers, it will be refetched or at least revalidated on navigation.

[domenic]

Current status: https://github.com/WICG/nav-speculation/pull/166 takes care of this for prefetch, but we need similar updates for prerender. Not sure on implementation and web platform tests status.

[nhiroki]

Chrome cancels prerendering when speculation rules are removed [CL]. As far as I can see, there're no WPTs for this behavior.