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

yoshisatoyanagisawa left a comment (w3c/ServiceWorker#1764)

Thanks for the follow-up. I feel I might not have addressed your points clearly in my previous response, so let me clarify my perspective on each.

**Regarding the opt-in/out of racing and SW reinstallation**: In my view, the decision to use racing is less about varying network conditions and more about whether the server-side is willing to accept the additional load. The motivation of the feature is that developers opt for `race-network-and-cache` because disk/storage access can be slow, rather than simply because the network is fast. However, providing the option not to race is important for those who need to prioritize minimizing server load.

**Regarding different strategies for different routes**: A potential use case for route-specific strategies would be a "niche" optimization where a developer races resources critical to LCP (Largest Contentful Paint) to ensure they arrive as fast as possible, while relying solely on the cache for other resources to reduce server pressure—even if those resources take slightly longer to load.

**Regarding the UA disabling racing (e.g., 5G metered vs. Wi-Fi)**: I understand your point now. I was previously thinking about how developers use the Resource Timing API to send data to the server for research and statistics. From that perspective, it's discernible on the server side. However, if you are referring to the web app knowing this on the client side, I’m not sure what behavior the app would change based on that information. Beyond server-side statistics, what specific use cases do you have in mind for the client-side web app?

**Regarding precision**: While I agree that bypassing the fetch handler reduces "noise" from JavaScript and IPC, I’m not sure how impactful that is compared to the much larger noise inherent in network or HDD access. In terms of measurement precision, both approaches use the same underlying timers, so the results should be comparable. If you believe the precision difference is significant, I would appreciate more details on that.

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

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