ServiceWorkerAutoPreload

[sisidovski]

Request for Mozilla Position on an Emerging Web Specification

• Specification title: ServiceWorkerAutoPreload
• Specification or proposal URL (if available):
• Explainer URL (if available): https://github.com/explainers-by-googlers/service-worker-auto-preload
• Proposal author(s) (@-mention GitHub accounts): @sisidovski
• Caniuse.com URL (optional):
• Bugzilla URL (optional):
• Mozillians who can provide input (optional):
• WebKit standards-position: ServiceWorkerAutoPreload WebKit/standards-positions#359

Other information

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.

The status in chromium can be tracked from https://chromestatus.com/feature/5194817700364288

This is an early-stage idea but we'd love early engagement from other implementers.

[asutherland]

This is somewhat moot since w3c/ServiceWorker#1756 merged into the spec in late July with feedback from webkit in addition to it being a chromium proposal. That said, the fetch PR whatwg/fetch#1737 that integrates use of the static routing proposal (which we are positive on) Lookup Race Response algorithm that is necessary for fetch integration has not landed.

I had seen the proposal go by and read it before losing track of this issue; this was a good proposal since it provides an optional fast-path for pass-through fetch that allows for some implementer flexibility, can be opted out-of, and builds on the static routing API infrastructure so it's also not adding that much.

I think we should be positive on this, and since it's already in the SW spec I don't think we'll need a PR, we can just close this when we mark positive.