Intent to Ship: Skip service worker no-op fetch handler
Yoshisato Yanagisawa
Contact emails
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
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).
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).
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
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
Contact emails
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
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).
--
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
On Tue, Mar 7, 2023 at 1:03 AM 'Yoshisato Yanagisawa' via blink-dev <blin...@chromium.org> wrote:Contact emails
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
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?
Yoav Weiss
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
Explainer
https://github.com/yoshisatoyanagisawa/service-worker-skip-no-op-fetch-handler
Specification
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
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/4469Therefore, it might be safe to say that the number of run-time fetch handler updates is too small and not observable.
Daniel Bratell
LGTM2
/Daniel
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXAGz4JT_7iDFfH2txo9swuxpK3mSmscYfdjFyGbkyh4A%40mail.gmail.com.
