WebKit
ServiceWorkerAutoPreload
WebKittens
No response
Title of the spec
ServiceWorkerAutoPreload
URL to the spec
No spec yet. Please see the explainer.
URL to the spec's repository
No response
Issue Tracker URL
No response
Explainer URL
https://github.com/explainers-by-googlers/service-worker-auto-preload
TAG Design Review URL
https://github.com/w3ctag/design-reviews/issues/963
Mozilla standards-positions issue URL
https://github.com/mozilla/standards-positions/issues/1036
WebKit Bugzilla URL
No response
Radar URL
No response
Description
This API is a new loading strategy for ServiceWorker. ServiceWorkerAutoPreload is a mode where the browser issues a network request (i.e. a regular request which may result in a HTTP cache hit or an actual fetch) in parallel with the ServiceWorker bootstrap, and consumes the network request result inside the fetch handler.
This is an early-stage idea but we'd love early engagement from other implementers.
How does this avoid potential problems with the main document and service worker having different policies in place? E.g., you might end up preloading something that the service worker would have rejected.
Given that this is only for Navigation I think a better name would be "Navigation Auto Preload" or some such. The explainer does not make it very clear upfront which requests this ends up applying to.
How does this avoid potential problems with the main document and service worker having different policies in place? E.g., you might end up preloading something that the service worker would have rejected.
It's possible that preloaded requests are dispatched but eventually not used. However, we think it can be mitigated by applying this behavior only on the service worker in which the fetch handler result is always fallback (no respondWith() call in the fetch handler).
Given that this is only for Navigation I think a better name would be "Navigation Auto Preload" or some such. The explainer does not make it very clear upfront which requests this ends up applying to.
Thank you for the feedback. We should discuss more on the naming. In the alternative considered section in the explainer, we mention we're exploring this behavior for subresources as well, although our primary focus is for the main resource only. That's why the name doesn't specify "navigation". In addition to it, this API behavior is different from the navigation preload API, we should be careful not to make these confused in terms of the name.