Add an additional action - preparse (aka NSP)

[tvereecke]

We propose to add a third action called “preparse” (open for alternative names). Like prerendering, it fetches resources in advance; but unlike prerendering it does not execute JavaScript or render any part of the page in advance. (an action similar to No State Prefetch (NSP) in Chromium)

This new third action allows for more performance gains than a simple prefetch and would be a significant risk reduction compared to a full prerender (due to 1st party and 3rd party JS execution)

We have found that some of our customers are reluctant to enable Speculation Rules because the risk to their application of enabling pre-rendering is too great

Here are 3 (related) statements:

"Prerender is too risky because we don't know how it will affect analytics or features like product recommendations or recently viewed products" "For Prerender to work, the impact on the app needs to be fully understood and many different teams need to work together" "If we do it wrong, it can break our application. (e.g. analytics, personalization, price controls, targeting, ...)"

Existing alternatives with 2 different actions are suboptimal:

• Falling back to Prefetch is unlikely to deliver sufficient performance gains.
• Using Eagerness=conservative reduces the risk significantly, but due to the small time window the performance benefits are usually limited.

This new action also allows for progressive speculation rules, where the result of an eagerly triggered action (a lot of time) can be used for the less eager action.

• Preparse with eagerness "moderate" and Prerender with eagerness "conservative."
• Prefetch with eagerness "moderate" and Preparse with eagerness "conservative".
• Preparse with eagerness "eager" and only Prerender with eagerness "conservative".
• ...

Thank you for considering this option

[jeremyroman]

(In fact Chromium actually still has some code to support "prefetch_with_subresources" which invokes NSP.)

Lots of interesting questions to evaluate how useful this is (e.g., how large are the subresources that are not already in cache, assuming we're doing this same-origin; would we want to support this cross-origin or not).

On the spec side, probably the most interesting piece here would be formalizing more about how preloaded subresources are found (somewhere there is discussion on a GitHub issue about invoking the HTML parser in a way that will scan through <noscript> etc properly, in the context of <meta>, which I can dig up). It's simplest conceptually if everything is in Link header fields, but would that be enough?