This is a second time request for ServiceWorkerAutoPreload. The previous request was closed in https://github.com/w3ctag/design-reviews/issues/963. Now we have other browser interest, draft spec change, and the proposal was transferred into WICG. So let us ask the TAG review again.

こんにちは TAG-さん!

I'm requesting an early TAG design review of ServiceWorkerAutoPreload.

ServiceWorker fetch handlers are used for various reasons but there are many cases where developers use them with the intention of serving resources faster than the network, however in some cases ServiceWorker could be slower because of its startup. To fulfill their intention, this document proposes the introduction of “ServiceWorkerAutoPreload”, 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.

• Explainer¹: url

• User research: it is a well-studied phenomenon that faster sites are better for users, but we have not conducted any user studies specifically on this feature.

• Security and Privacy self-review²: url

• GitHub repo: url

• Primary contacts:

  • Shunya Shishido (@sisidovski), Google.

• Organization/project driving the design: Google Chrome browser loading team.

• This work is being funded by: Google

• Incubation and standards groups that have discussed the design: WICG

• Standards group(s) that you expect to discuss and/or adopt this work when it's ready: WebApp WG

• Multi-stakeholder feedback³:

  • Chromium comments:
  • Mozilla comments: https://github.com/mozilla/standards-positions/issues/1036
  • WebKit comments: https://github.com/WebKit/standards-positions/issues/359
  • https://github.com/WICG/proposals/issues/155#issuecomment-2873318636

• Major unresolved issues with or opposition to this design: so far we don't have unresolved issues.

• I have reviewed the TAG's Web Platform Design Principles

You should also know that...

• Spec change PR: https://github.com/w3c/ServiceWorker/pull/1756
• Previous TAG review request: https://github.com/w3ctag/design-reviews/issues/963

<!------------------------------------------------------------------------------------ CAREFULLY READ AND DELETE CONTENT BELOW THIS LINE BEFORE SUBMITTING Use links to content rather than pasting text into this issue. Issues are ephemeral and most of the material we are asking for has long term value. Please preview the issue and check that the links work before submitting. Please make sure anyone with the link can access the document. We may refuse to review anything that is not public. ¹ An explainer must address user needs and contain examples of use. See our [explanation of how to write a good explainer](https://tag.w3.org/explainers/). ² Even for early-stage ideas, a Security and Privacy questionnaire helps us understand potential security and privacy issues and mitigations for your design, and can save us asking redundant questions. See https://www.w3.org/TR/security-privacy-questionnaire/. ³ For your own organization, you can simply state the organization's position instead of linking to it. This includes items on [Mozilla standards-positions](https://github.com/mozilla/standards-positions), and [WebKit standards-positions](https://github.com/WebKit/standards-positions). Chromium doesn't have a standards-positions repository and [prefers](https://source.chromium.org/chromium/chromium/src/+/main:docs/standards/positions/GoogleChrome/README.md) to use comments from the teams that maintain the relevant area of their codebase. -->