Contact emails yyanagis...@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 <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EServiceWorker> 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 <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> ? 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 <https://chromestatus.com/>, and modified by hand. -- 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+unsubscr...@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.
