Intent to Ship: Navigation Preload for Service Worker

[Matt Falkenhagen]

Contact emails

fal...@chromium.org, ho...@chromium.org, kenji...@chromium.org

Spec

The Navigation Preload changes have been merged to the service worker spec in mid December 2016 (TAG review: discussion scheduled for this week)

Summary

Navigation preload is an extension of the Service Worker API which lets the browser send a “preload” network request for a navigation without blocking on the fetch event handler of the relevant service worker. The service worker can then have access to the preload response inside its fetch event handler.

Authors opt in to this behavior by calling ServiceWorkerRegistration.navigationPreload.enable().

A basic use of the feature is to simply respond with the preload response. That is, in the fetch event handler do:

if (event.request.mode == ‘navigate’)

 event.respondWith(event.preloadResponse)

An advanced use is to teach the server to respond to the navigation preload request with fresh data only, such as news posts, tweets, etc. Then the service worker synthesizes a response using both fresh data and common “app shell” resources from the local cache.

In the default case, where navigation preload is not enabled, the browser first dispatches the fetch event to the service worker, which might require starting the worker. The browser then only starts fetching the URL if the worker falls back to network, by not calling event.respondWith(), or manually requests it by doing something like event.respondWith(fetch(request)).

Link to “Intent to Implement” blink-dev discussion

Intent to implement

Intent to experiment

Feedback summary from the experiment

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Demo link

https://developers.google.com/web/updates/2017/02/navigation-preload

https://mattto.github.io/sw/demo/navigation-preload/

Debuggability

Yes, DevTools shows the navigation preload request and allows debugging a service worker.

Interoperability and Compatibility Risk

The API has been actively discussed by Mozilla, Apple, Microsoft and developers since its inception in the summer of 2016. All browser vendors have been generally positive about this addition; see in particular the notes from the F2F on July 30 2016.

More recently, the API was on the agenda for the Service Worker F2F (April 3-4 2017). The event was attended by representatives from Apple, Microsoft, Mozilla, and Facebook. We discussed the readiness of this feature. Here is the outcome:

• Positive feedback from Facebook and promising early performance insights from the origin trial running in Chrome 58 (beta as of now).

• No objections to Chrome shipping from other vendors.

Edge: Public support

Firefox: Public support

Safari: Public support

Web developers:

• Positive (see Feedback summary for the Origin Trial experiment in Chrome M58)

• The early performance insights are very promising.

• While we are confident that the feature will deliver on its promises, we will keep monitoring feedback and our metrics to confirm that this holds true as M58 reaches our Stable users. This feature being a progressive enhancement, we have the flexibility to temporarily disable the feature if we need to.

Of all the tests for web-exposed behavior, are any not in web-platform-tests? Please explain and link to bugs.

Most of the tests are web-platform-tests. We wrote some early browser tests before the feature was working end-to-end. We will investigate whether these are redundant now or can be converted to WPT (bug).

OWP launch tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=661071

Entry on the feature dashboard

https://www.chromestatus.com/feature/5734842339688448

[Philip Jägenstedt]

Thanks for filing the wpt issue, and the links for vendor support!

I've looked over the things that are [OriginTrialEnabled=ServiceWorkerNavigationPreload] in our IDL, which led me to FetchEvent's preloadResponse promise and the fact that the spec says something odd here:

https://w3c.github.io/ServiceWorker/#fetchevent-interface

Adding a required dictionary member has roughly the same compat constraints as removing the constructor entirely, i.e. it only works if almost no code currently tries to use the constructor.

Can you make sure the spec is updated and that Blink then matches the spec's FetchEventInit? With that, LGTM1.

[Matt Falkenhagen]

Thanks, that makes sense. Filed https://github.com/w3c/ServiceWorker/issues/1114

[Dimitri Glazkov]

LGTM2

[Chris Harrelson]

LGTM3

LGTM2

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.