search

WebKit / standards-positions

WebKit's positions on emerging web specifications
https://webkit.org/standards-positions/
240 stars 18 forks source link

ServiceWorkerAutoPreload #359

Open sisidovski opened 4 weeks ago

sisidovski commented 4 weeks ago

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.

annevk commented 2 weeks ago

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.

sisidovski commented 1 week ago

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.