Re: [w3c/ServiceWorker] Add race-network-and-cache source to static routing api. (PR #1764)

youennf left a comment (w3c/ServiceWorker#1764)

> If [the elapsed time](https://github.com/WICG/service-worker-static-routing-api/blob/main/resource-timing-api.md#cache-rule-specified) between `cacheLookupStart` and `responseStart` is large, the cache storage access can be slow. The `race-network-and-cache` can be chosen for the case.

If decision is made this way, that would require reinstalling the service worker whenever a website wants to opt-in/out of racing. This seems inadequate as the usefulness of racing may depend on varying network conditions.

I would have expected that racing could be enabled/disabled without the need to reinstall the service worker.
Similarly, is there a use case for having different race strategies for different cache routes of a single service worker?

> I think this can be guessed from the resource timing API. Especially seeing the [workerFinalRouterSource](https://www.w3.org/TR/resource-timing/#dom-performanceresourcetiming-workerfinalroutersource) ratio.

It can be guessed but not known for sure, especially if the UA is disabling racing in some specific cases (5G metered vs. wifi for instance).

> However, the same thing can be done with the fetch handler.

Not with the same precision. A fetch handler adds JS, different IPC messages and so on.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/pull/1764#issuecomment-3871421213
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/pull/1764/c3871421213@github.com>