Service Worker Navigation Preload origin trial results so far

39 views
Skip to first unread message

Matt Falkenhagen

unread,
Apr 7, 2017, 3:36:55 AM4/7/17
to blink-dev, worke...@chromium.org, experimen...@chromium.org

Summary

The Service Worker Navigation Preload origin trial started in Chrome 57. Chrome 58 is the last release it is intended to be available as an origin trial. We have collected feedback and are sharing it according to the Origin Trials process.


Intent to experiment: https://groups.google.com/a/chromium.org/d/msg/blink-dev/0-6bmy1cOnw/E_IQ3l23FgAJ

Contact email

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

Spec and chromestatus.com entry

Developer interest

As of 2017-04-07, 27 origins have registered for access to the origin trial. This may appear small, but these origins make up a significant percentage of the web. Notably, they include Facebook and several Google sites. In addition, there are non-trivial prerequisites in order to take advantage of this API (e.g., HTTPS, an existing service worker integration).

Developer feedback

Facebook reports that the feature saved approximately 150 ms on page load time in their experiment, which matches their expectations. However, they reported a crash bug in Chrome 57 Stable (now fixed), so could only test on Beta/Dev/Canary (Chrome 58 and 59). The most recent Stable update contains the bug fix, and they plan to re-run the experiment more widely.


Google sites are starting up their experiments and we expect results within weeks. These sites report that this feature is critical to adopting service worker.


When enabled, navigation preload occurs for all navigation requests, even if the service worker is already running. Some developers proposed changing this particular behavior or extending the API to allow skipping navigation preload when the service worker is already running. We are exploring alternative solutions to the underlying use case and believe that this could be addressed by extending the existing API if warranted. Feedback from other developers and discussion at last year’s TPAC and the recent service worker F2F was that the default of always using navigation preload is desirable.


Other feedback received:

  • “This bug is currently problematic: http://crbug.com/691503

    • This bug was fixed since.

  • “it would be very useful if the preloadResponse could give a different error for being offline than other errors, so we can detect whether it's a normal offline case or whether we've encountered a bug (in our own code or in the navigation preload feature).”

    • This can be a later enhancement for general network APIs. There was discussion of extending the Fetch API to give more detailed errors at the service worker F2F this week.

  • “more example are required”

    • We will discuss additional documentation and examples with our developer advocates team.

Lessons learned from our goals for experimentation

The primary objective of the origin trial was to test performance in the real world. With Facebook’s preliminary result we have some confidence that the feature is performing as expected. We are awaiting results from their wider experiment and from other developers.

Timeline

First Stable release enabled: Chrome 57: 2017-03-14

First Stable release with feature shipped/disabled: Chrome 59, expected early June


We are aiming to ship the feature in Chrome 59. If we receive feedback from other sites that the feature is not working well, we are prepared to unship before reaching Stable. An intent to ship is forthcoming.

Dimitri Glazkov

unread,
Apr 7, 2017, 12:29:08 PM4/7/17
to Matt Falkenhagen, blink-dev, worke...@chromium.org, experimen...@chromium.org
Thank you for sharing this insight, Matt!
Reply all
Reply to author
Forward
0 new messages