Intent to Ship: Skip service worker no-op fetch handler

777 views
Skip to first unread message

Yoshisato Yanagisawa

unread,
Mar 6, 2023, 7:03:45 PM3/6/23
to blink-dev

Contact emails

yyana...@google.com


Explainer

https://github.com/yoshisatoyanagisawa/service-worker-skip-no-op-fetch-handler


Specification

https://github.com/w3c/ServiceWorker/pull/1672


Summary

The feature makes the navigation of pages with no-op service worker fetch handlers fast by skipping them.


Some sites have a no-op (no operation) fetch listener (e.g. onfetch = () => {}).  Since having the fetch listener was one of the requirements to be a progressive web app (PWA), we assume 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 listener 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 listener dispatch from the navigation critical path if a user agent identifies that all the service worker's fetch listeners are no-ops.


From version 112, Chromium starts to show console warnings if all the service worker’s fetch listeners are no-ops, and encourages developers to remove the useless fetch listeners.  Hopefully sites stop using the useless fetch listeners and we can deprecate the feature in the future.


Blink component

Blink>ServiceWorker


TAG review

https://github.com/w3ctag/design-reviews/issues/815


TAG review status

Issues addressed


Risks



Interoperability and Compatibility

We believe the change has very small compatibility risk.


Updating the no-op fetch handler in a service worker is ignored, which was not allowed to ignore before.  Upon our observation, this happens to a negligible amount (https://chromestatus.com/metrics/feature/timeline/popularity/4453).

https://github.com/yoshisatoyanagisawa/service-worker-skip-no-op-fetch-handler/#approaches-to-deal-with-the-handler-updates-after-the-initialization


Navigation Preload is ignored for the no-op fetch handler.  The spec requires the same resource fetched twice for no-op fetch handler due to lack of respondWith, which could result in two different network requests in rare situation, but this behavior only happens when they are misconfigured (a page was set up to send a Navigation Preload request they do not use).

https://github.com/yoshisatoyanagisawa/service-worker-skip-no-op-fetch-handler/#how-does-it-work-with-navigation-preload


Gecko: No signal (https://github.com/mozilla/standards-positions/issues/744)


WebKit: No signal (https://github.com/WebKit/standards-positions/issues/129)


Web developers: No signals. When you search with the query "A2HS", you will find many sites recommending you to add a no-op fetch handler (e.g. addEventListener("fetch", ()=>{})).  Thus, you can easily assume that people who want to make their site to be added to the home screen would just add the no-op fetch handler for that purpose.  Therefore, having the no-op fetch handler is common among sites (upon our investigation on popular site fetch handler usage, 3-5% of them were affected). Such sites will benefit from shipping this performance improvement, but we do not have specific examples of sites supporting this Intent.  (Probably, if they were aware of the problem, they would just remove the empty fetch handler.)


Other signals:


WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

There are no special risks for WebView-based applications.



Debuggability

If a service worker is affected, its "Fetch handler type" field in chrome://serviceworker-internals/ will be EMPTY_FETCH_HANDLER.  From version 112, there will be a console warning saying "Fetch event handler is recognized as no-op. No-op fetch handler may bring overhead during navigation. Consider removing the handler if possible." if the service worker is affected.


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes


Is this feature fully tested by web-platform-tests?

No.  The specification proposal adds this as an optional behavior, so testing it with web platform tests is not very useful. (Note that no existing web platform tests needed to be updated to allow this behavior, since the observable changes are only visible in edge cases.)


Flag name

#skip-service-worker-fetch-handler


Requires code in //chrome?

False


Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1347319


Estimated milestones


DevTrial on desktop

111


DevTrial on Android

111



Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

https://github.com/w3c/ServiceWorker/pull/1672 is mostly finished, but still undergoing final review by the spec mentor.


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5136946693668864


This intent message was generated by Chrome Platform Status, and modified by hand.



Yoav Weiss

unread,
Mar 7, 2023, 3:19:20 AM3/7/23
to Yoshisato Yanagisawa, blink-dev
On Tue, Mar 7, 2023 at 1:03 AM 'Yoshisato Yanagisawa' via blink-dev <blin...@chromium.org> wrote:

Contact emails

yyana...@google.com


Explainer

https://github.com/yoshisatoyanagisawa/service-worker-skip-no-op-fetch-handler


Specification

https://github.com/w3c/ServiceWorker/pull/1672


Summary

The feature makes the navigation of pages with no-op service worker fetch handlers fast by skipping them.


Some sites have a no-op (no operation) fetch listener (e.g. onfetch = () => {}).  Since having the fetch listener was one of the requirements to be a progressive web app (PWA), we assume 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 listener 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 listener dispatch from the navigation critical path if a user agent identifies that all the service worker's fetch listeners are no-ops.


From version 112, Chromium starts to show console warnings if all the service worker’s fetch listeners are no-ops, and encourages developers to remove the useless fetch listeners.  Hopefully sites stop using the useless fetch listeners and we can deprecate the feature in the future.


Blink component

Blink>ServiceWorker


TAG review

https://github.com/w3ctag/design-reviews/issues/815


TAG review status

Issues addressed


Risks



Interoperability and Compatibility

We believe the change has very small compatibility risk.


Updating the no-op fetch handler in a service worker is ignored, which was not allowed to ignore before.  Upon our observation, this happens to a negligible amount (https://chromestatus.com/metrics/feature/timeline/popularity/4453).


It seems like we don't yet have data from this.
Can you explain this counter a bit more? Doesn't it also count cases where an operational fetch handler is updated after initialization?
 
 
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPNB-6VZntByJg-K_GNFb4xENkOEsmR8GewsKNJFyWbqnsWAHw%40mail.gmail.com.

Yoshisato Yanagisawa

unread,
Mar 7, 2023, 4:12:36 AM3/7/23
to Yoav Weiss, blink-dev


2023年3月7日(火) 17:19 Yoav Weiss <yoav...@chromium.org>:


On Tue, Mar 7, 2023 at 1:03 AM 'Yoshisato Yanagisawa' via blink-dev <blin...@chromium.org> wrote:

Contact emails

yyana...@google.com


Explainer

https://github.com/yoshisatoyanagisawa/service-worker-skip-no-op-fetch-handler


Specification

https://github.com/w3c/ServiceWorker/pull/1672


Summary

The feature makes the navigation of pages with no-op service worker fetch handlers fast by skipping them.


Some sites have a no-op (no operation) fetch listener (e.g. onfetch = () => {}).  Since having the fetch listener was one of the requirements to be a progressive web app (PWA), we assume 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 listener 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 listener dispatch from the navigation critical path if a user agent identifies that all the service worker's fetch listeners are no-ops.


From version 112, Chromium starts to show console warnings if all the service worker’s fetch listeners are no-ops, and encourages developers to remove the useless fetch listeners.  Hopefully sites stop using the useless fetch listeners and we can deprecate the feature in the future.


Blink component

Blink>ServiceWorker


TAG review

https://github.com/w3ctag/design-reviews/issues/815


TAG review status

Issues addressed


Risks



Interoperability and Compatibility

We believe the change has very small compatibility risk.


Updating the no-op fetch handler in a service worker is ignored, which was not allowed to ignore before.  Upon our observation, this happens to a negligible amount (https://chromestatus.com/metrics/feature/timeline/popularity/4453).


It seems like we don't yet have data from this.
Can you explain this counter a bit more? Doesn't it also count cases where an operational fetch handler is updated after initialization?
 

Sure.  The counter has been added in https://chromium-review.googlesource.com/c/chromium/src/+/4190509, and cherry-picked in M111, which is now eary stable according to https://chromereleases.googleblog.com/.  There is the counter to watch all event handler updates in service worker https://chromium-review.googlesource.com/c/chromium/src/+/4259225, and we can see some numbers. https://chromestatus.com/metrics/feature/timeline/popularity/4469
Therefore, it might be safe to say that the number of run-time fetch handler updates is too small and not observable.

Yoav Weiss

unread,
Mar 7, 2023, 6:58:23 AM3/7/23
to Yoshisato Yanagisawa, blink-dev
LGTM1

On Tue, Mar 7, 2023 at 10:12 AM Yoshisato Yanagisawa <yyana...@google.com> wrote:


2023年3月7日(火) 17:19 Yoav Weiss <yoav...@chromium.org>:


On Tue, Mar 7, 2023 at 1:03 AM 'Yoshisato Yanagisawa' via blink-dev <blin...@chromium.org> wrote:

Glad to see the PR in almost-landing condition! :) Please follow up with any extra effort required to actually land it.
 

Summary

The feature makes the navigation of pages with no-op service worker fetch handlers fast by skipping them.


Some sites have a no-op (no operation) fetch listener (e.g. onfetch = () => {}).  Since having the fetch listener was one of the requirements to be a progressive web app (PWA), we assume 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 listener 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 listener dispatch from the navigation critical path if a user agent identifies that all the service worker's fetch listeners are no-ops.


From version 112, Chromium starts to show console warnings if all the service worker’s fetch listeners are no-ops, and encourages developers to remove the useless fetch listeners.  Hopefully sites stop using the useless fetch listeners and we can deprecate the feature in the future.


Blink component

Blink>ServiceWorker


TAG review

https://github.com/w3ctag/design-reviews/issues/815


TAG review status

Issues addressed


Risks



Interoperability and Compatibility

We believe the change has very small compatibility risk.


Updating the no-op fetch handler in a service worker is ignored, which was not allowed to ignore before.  Upon our observation, this happens to a negligible amount (https://chromestatus.com/metrics/feature/timeline/popularity/4453).


It seems like we don't yet have data from this.
Can you explain this counter a bit more? Doesn't it also count cases where an operational fetch handler is updated after initialization?
 

Sure.  The counter has been added in https://chromium-review.googlesource.com/c/chromium/src/+/4190509, and cherry-picked in M111, which is now eary stable according to https://chromereleases.googleblog.com/.  There is the counter to watch all event handler updates in service worker https://chromium-review.googlesource.com/c/chromium/src/+/4259225, and we can see some numbers. https://chromestatus.com/metrics/feature/timeline/popularity/4469
Therefore, it might be safe to say that the number of run-time fetch handler updates is too small and not observable.

Oh, ok. So after over a week in Stable, we see 0.00015% for the loose upper bound. That's reassuring! :)

Daniel Bratell

unread,
Mar 8, 2023, 11:27:45 AM3/8/23
to Yoav Weiss, Yoshisato Yanagisawa, blink-dev

slightlyoff via Chromestatus

unread,
Mar 8, 2023, 11:32:41 AM3/8/23
to blin...@chromium.org
LGTM3
Reply all
Reply to author
Forward
0 new messages