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?

[krzksz]

Huge +1 to this one as we're facing similar challenges on our platform when it comes to Speculation Rules. We want to roll them out to everyone in a safe and impactful way. Unfortunately, the less conservative we get the higher the risk that we'll break merchants' scripts and analytics. Realistically speaking, I don't think we'll ever be able to do prerender, there are just too many moving parts that we don't control.

Our TTFB is quite good, so using preparse/prescan/prefetch_with_subresources (even with the conservative eagerness) would benefit our users way more than prefetch.

My idea was that it could "just trigger" the preload scanner over the HTML response. For us this should be enough to make sure all of the critical resources are already in the cache.

[domenic]

Thanks very much for the comment @krzksz. Hearing that a large platform would be willing to use this definitely ups the priority.

We currently have an old implementation behind a flag: you can test it by passing --enable-blink-features=SpeculationRulesPrefetchWithSubresources on the command line, and using "prefetch_with_subresources" instead of "prefetch" or "prerender". However, this code hasn't been touched in a few years, so there are caveats to be aware of:

• We're not sure if it works with document rules (it might! but we haven't tested recently)
• There is no DevTools support at all
• The implementation is based on an older architecture which is probably not as fast as it could be
• It gets disabled under a few circumstances that might be confusing to debug:
  • If there is a <link rel=next> pointing to the same URL
  • If third party cookies are blocked for the user
  • If there was another prefetch with subresources within the last 500 ms
  • If the URL was navigated to within the last 5 minutes
  • If there are too many tabs open

Given these limitations, I think it would be pretty frustrating to try even behind a flag. But I think we could work on some basic DevTools support and fixing of the above unexpected limitations during Q3 to get ready for a Dev Trial or Origin Trial, if Shopify's interested in experimenting!

Our TTFB is quite good, so using preparse/prescan/prefetch_with_subresources (even with the conservative eagerness) would benefit our users way more than prefetch.

Keep in mind that prefetch can speed up more than just TTFB though, since it downloads the whole resource and keeps it in memory, not just the first byte!

[krzksz]

Thanks for the overview @domenic!

The prefetch_with_subresources definitely sounds like something I would personally want us to push.

Keep in mind that prefetch can speed up more than just TTFB though, since it downloads the whole resource and keeps it in memory, not just the first byte!

Noted! What I'm trying to say is that with our TTFB there seems to enough time for the browser to do more then just prefetch, even with the conservative eagerness.

But I think we could work on some basic DevTools support and fixing of the above unexpected limitations during Q3 to get ready for a Dev Trial or Origin Trial, if Shopify's interested in experimenting!

We're currently restarting the work on rolling out Speculation Rules after we had to pause it last year because of some browser bugs. It's a bit early for us to commit to anything I think, but I'll @yoavweiss chime in as well. He's championing the project this time.