LGTM2
/Daniel
On 2023-03-07 12:57, Yoav Weiss wrote:
LGTM1
On Tue, Mar 7, 2023 at 10:12 AM Yoshisato Yanagisawa
<yyanagis...@google.com> wrote:
2023年3月7日(火) 17:19 Yoav Weiss <yoavwe...@chromium.org>:
On Tue, Mar 7, 2023 at 1:03 AM 'Yoshisato Yanagisawa' via
blink-dev <blink-dev@chromium.org> wrote:
Contact emails
yyanagis...@google.com
Explainer
https://github.com/yoshisatoyanagisawa/service-worker-skip-no-op-fetch-handler
<https://github.com/yoshisatoyanagisawa/service-worker-skip-no-op-fetch-handler>
Specification
https://github.com/w3c/ServiceWorker/pull/1672
<https://github.com/w3c/ServiceWorker/pull/1672>
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
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EServiceWorker>
TAG review
https://github.com/w3ctag/design-reviews/issues/815
<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://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! :)
https://github.com/yoshisatoyanagisawa/service-worker-skip-no-op-fetch-handler/#approaches-to-deal-with-the-handler-updates-after-the-initialization
<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
<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
<https://github.com/mozilla/standards-positions/issues/744>)
WebKit: No signal
(https://github.com/WebKit/standards-positions/issues/129
<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
<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
<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
<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
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPNB-6VZntByJg-K_GNFb4xENkOEsmR8GewsKNJFyWbqnsWAHw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
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/CAL5BFfXAGz4JT_7iDFfH2txo9swuxpK3mSmscYfdjFyGbkyh4A%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXAGz4JT_7iDFfH2txo9swuxpK3mSmscYfdjFyGbkyh4A%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
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/6eee0a53-cfa6-7574-5c1c-c4f39238cd86%40gmail.com.
