Skip no-op service worker fetch handler

[yoshisatoyanagisawa]

Wotcher TAG!

I'm requesting a TAG review of skip no-op service worker fetch handler.

Some sites have a no-op (no operation) fetch handler (e.g. onfetch = () => {}). Since having the fetch handler was one of the requirements to be a progressive web app (PWA), we assume that they did that to make their site recognized as PWA. However, it only brings overheads to start a service worker and execute a no-op handler without bringing any feature benefits like caching or offline capabilities because the code does nothing. To make the navigation to such pages faster, we would like to omit the service worker start and the handler execution from the navigation critical path if a user agent identifies that the service worker fetch handler is no-op.

This is mostly a behind-the-scenes performance improvement. However, it can subtly change the behavior in edge cases, such as dynamically-updated fetch handlers.

• Explainer (minimally containing user needs and example code): url
• User research: Upon our investigation on popular site fetch handler usage, 3-5% of them were affected.
• Security and Privacy self-review: url
• GitHub repo (if you prefer feedback filed there): url
• Primary contacts (and their relationship to the specification):
  • Yoshisato Yanagisawa (@yoshisatoyanagisawa), Google
• Organization/project driving the design: Google Chrome
• External status/issue trackers for this feature (publicly visible, e.g. Chrome Status):
  • Service Worker Working Group Issue
  • ChromeStatus
  • Mozilla standards position
  • WebKit standards position

Further details:

• [x] I have reviewed the TAG's Web Platform Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): W3C Service Workers Working Group
• The group where standardization of this work is intended to be done ("unknown" if not known): W3C Service Workers Working Group (plus maybe WHATWG for related Fetch changes)
• Existing major pieces of multi-stakeholder review or discussion of this design: not yet.
• Major unresolved issues with or opposition to this design: n/a
• This work is being funded by: Google

You should also know that...

[please tell us anything you think is relevant to this review]

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

[ylafon]

We looked at this during our last teleconference and we have the following observation: If it is still common practise to register a (potentially) noop, then it should be advertised that it is not a good practise. In the meantime, we see this as a good temporary optimisation, but it would be good to easily roll it back when the number of such cases are low enough. Thanks