PSA: NoStatePrefetch status (replaces prerendering)

160 views
Skip to first unread message

Egor Pasko

unread,
May 31, 2018, 8:10:17 AM5/31/18
to blink-dev
== TL;DR:

The NoStatePrefetch feature (enabled since M63) prefetches resources of likely-to-be-loaded web pages into the HTTP cache. In future releases we are introducing the “Purpose: prefetch” header to allow web servers distinguish prefetch traffic from user-initiated page load traffic.

== Some Background

NoStatePrefetch is a mechanism for speculative prefetching of webpages and their subresources that are on a critical path of page loading *without* executing any JavaScript or creating a complex state of the web platform. This system is not purely “no state” because HTTP cache allows to create cookies and other state related to validating cache entries.

The detailed design for the feature is covered in [1]. The Chrome Privacy Whitepaper ([2]) in section “Network predictions” covers types of prefetching where NoStatePrefetch is used as a mechanism (more about these types of prefetching below).

It is important to note that NoStatePrefetch is not an API, it is an optional mechanism used by the network prediction service to potentially speed up future navigations. Also, while it is a Chrome feature and not a Web Platform feature, it can be triggered by Web Platform features such as <link rel=prerender>.

No explicit indication is given by Chrome that a NoStatePrefetch is occurring. This is in contrast to other speculative actions that have existed over time, such as the JS page visibility API used by prerender, or the “Purpose: prefetch” header that is sent when a <link rel=prefetch> is done [9].

== Current Status

Milestone where NoStatePrefetch was enabled for all users on Stable: M63. Link to chromestatus: [3].

Having NoStatePrefetch enabled means that in a few cases Chrome can decide to fetch a URL, parse its resource, fetch the subresources discoverable by preload scanning [4] and put the subset of cacheable ones to HTTP disk cache.

The mechanism can be initiated currently only in these cases:

(a) Based on past typing in the Omnibox, Chrome auto-completes a URL, which gets prefetched before the user explicitly asks to navigate to it

(b) A web page has element <link rel=prerender>, which gets prefetched. As usual, Chrome can decide not to prefetch to save resources. This limitation triggers, for example, when prefetch of the same page is requested too often. Running prefetch on a page does _not_ affect its visibility state [10], as the page runs no scripts.

(c) The Custom Tabs API mayLaunchUrl() also triggers a NoStatePrefetch, again subject to throttling

These cases formerly used to initiate Prerender. Prerender turndown was announced in [5]. The whitepaper also lists “AMP prefetching”, which was switched to a prerender-like system and does _not_ involve NoStatePrefetch.

== How to Detect NoStatePrefetch

While we are working on adding the “Purpose: prefetch” header when this feature triggers, one can locally observe the effects of NoStatePrefetch using these techniques:

* DevTools does _not_ report NoStatePrefetch, but one can detect that it was in the works by seeing resources fetched from cache right after the cache is cleared. There are no plans to feature these prefetches in DevTools: [6].

* The omnibox prediction rules can be inspected by browsing chrome://predictors.

* During prefetch a renderer process appears in the Task Manager briefly.

== Remaining Work

We are adding the “Purpose: prefetch” for all requests originating from this mechanism to distinguish it from user-initiated traffic. Bug for tracking: [7]. ETA is M69.

Another piece of remaining work is simplifying the prefetch/prerender codebase. Currently NoStatePrefetch uses a few bits of Prerender, and many of those bits are no longer necessary. Tracked at [8].

== References

[1] NoState Prefetch design
[2] Privacy Whitepaper
[3] NoState Prefetch feature on chromestatus:
[4] Preload scanner speedup announcement
[5] Prerender turndown announcement
[6] Issue: Display information about NoStatePrefetch in DevTools
[7] Issue: Add request header for NoState Prefetch
[8] Issue: Remove Prerender code
[9] See ResourceFetcher::PrepareRequest in the chromium codebase.
[10] Parts of spec covering Page Visibility with Prerender

Egor Pasko

unread,
Jun 1, 2018, 1:35:50 PM6/1/18
to blink-dev
On Thu, May 31, 2018 at 2:10 PM Egor Pasko <pa...@chromium.org> wrote:
== TL;DR:

The NoStatePrefetch feature (enabled since M63) prefetches resources of likely-to-be-loaded web pages into the HTTP cache. In future releases we are introducing the “Purpose: prefetch” header to allow web servers distinguish prefetch traffic from user-initiated page load traffic.

== Some Background

NoStatePrefetch is a mechanism for speculative prefetching of webpages and their subresources that are on a critical path of page loading *without* executing any JavaScript or creating a complex state of the web platform. This system is not purely “no state” because HTTP cache allows to create cookies and other state related to validating cache entries.

The detailed design for the feature is covered in [1]. The Chrome Privacy Whitepaper ([2]) in section “Network predictions” covers types of prefetching where NoStatePrefetch is used as a mechanism (more about these types of prefetching below).

It is important to note that NoStatePrefetch is not an API, it is an optional mechanism used by the network prediction service to potentially speed up future navigations. Also, while it is a Chrome feature and not a Web Platform feature, it can be triggered by Web Platform features such as <link rel=prerender>.

No explicit indication is given by Chrome that a NoStatePrefetch is occurring. This is in contrast to other speculative actions that have existed over time, such as the JS page visibility API used by prerender, or the “Purpose: prefetch” header that is sent when a <link rel=prefetch> is done [9].

== Current Status

Milestone where NoStatePrefetch was enabled for all users on Stable: M63. Link to chromestatus: [3].

Having NoStatePrefetch enabled means that in a few cases Chrome can decide to fetch a URL, parse its resource, fetch the subresources discoverable by preload scanning [4] and put the subset of cacheable ones to HTTP disk cache.

The mechanism can be initiated currently only in these cases:

(a) Based on past typing in the Omnibox, Chrome auto-completes a URL, which gets prefetched before the user explicitly asks to navigate to it

(b) A web page has element <link rel=prerender>, which gets prefetched. As usual, Chrome can decide not to prefetch to save resources. This limitation triggers, for example, when prefetch of the same page is requested too often. Running prefetch on a page does _not_ affect its visibility state [10], as the page runs no scripts.

(c) The Custom Tabs API mayLaunchUrl() also triggers a NoStatePrefetch, again subject to throttling

Colleagues reminded me that we no longer use nostate-prefetch for mayLaunchUrl (preconnect is done instead). We may reconsider If usage of mayLaunchUrl() increases.

Jeffrey Yasskin

unread,
Jun 1, 2018, 1:56:51 PM6/1/18
to pa...@chromium.org, blink-dev
The Purpose header needs to be specified somewhere. The only attempt I see so far is https://github.com/w3c/resource-hints/issues/74. https://bugs.webkit.org/show_bug.cgi?id=46529 discusses an old attempt to go through the HTTP WG, but doesn't link to the threads there.

Aligning the header marking Chrome-side speculative prefetch with the header marking Web Platform speculative prefetch is probably a good idea, but talking to people outside the Blink community might reveal a problem.

Jeffrey

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAH3q7_kowrO9OnDdEb3bzixdDTPXsxQjwPiQBJ6gZ6r71d9-iw%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages