Thanks for getting the spec PR landed, and for the clarifications on when 
the preload will be triggered. LGTM1.

-- Dan

On Sunday, July 27, 2025 at 10:06:56 PM UTC-7 yyana...@chromium.org wrote:

>
>
> 2025年7月28日(月) 13:05 Shunya Shishido <sisid...@chromium.org>:
>
>>
>>
>> On Fri, Jul 25, 2025 at 2:37 PM Yoshisato Yanagisawa <
>> yyana...@chromium.org> wrote:
>>
>>>
>>>
>>> 2025年7月25日(金) 10:44 'Daniel Clark' via blink-dev <blin...@chromium.org>:
>>>
>>>> This looks like a nice optimization. 
>>>>
>>>> > Specification
>>>> > https://github.com/w3c/ServiceWorker/pull/1756
>>>>
>>>> What needs to happen for this PR to land? It looks like there are a 
>>>> couple minor things from 2 weeks ago that need to be addressed. Since the 
>>>> WebKit reviewer has now approved, could it be landed after that?
>>>>
>>>
>>> I am a reviewer of the PR, and the remaining part is addressing comments 
>>> there.
>>>
>> Comments were resolved, I believe now it's ready to be landed.
>>  
>>
>
> Thank you.  LGTM, merged.
>  
>
>>  
>>>
>>>> Regarding a site's eligibility for the feature -- could you clarify the 
>>>> criteria you plan to ship with? The explainer section at 
>>>> https://github.com/WICG/service-worker-auto-preload?tab=readme-ov-file#eligibility-criteria
>>>>  seems 
>>>> to have been written before the experiment 
>>>> <https://github.com/WICG/service-worker-auto-preload/issues/3>, so I'm 
>>>> curious as to whether your thinking on that is still the same.
>>>>
>>>
>>> Upon the PR, there are no additional criteria needed.  Network requests 
>>> may always be sent if the feature is not explicitly disabled.
>>> I hope @Shunya Shishido to explain the details.
>>>
>> Yes. The spec says that a user agent may dispatch a network request 
>> unless there is an opt-out 
>> <https://github.com/WICG/service-worker-auto-preload?tab=readme-ov-file#opt-out>
>>  
>> signal via the static routing API. In Chrome, based on the previous 
>> experiment result 
>> <https://github.com/WICG/service-worker-auto-preload/issues/3>, we'll 
>> enable this optimization when the service worker is not running. In the 
>> future, we may want to implement another criteria such as higher rates of 
>> fetch handler results are fallback for further optimization.
>>  
>>
>>>  
>>>
>>>> Also, point (1) there is not so clear :"Higher rates of fetch handler 
>>>> results are fallback."  Is there a specific rate you have in mind, and how 
>>>> is that determined?
>>>>
>>> Again we'll enable this when the service worker is not running. For the 
>> fetch handler fallback rate, we don't have this mechanism yet, and we need 
>> another study to determine the threshold. But we believe it's worth 
>> exploring in the future since there are so many sites using service workers 
>> and the main resource fetch handler results are always fallback.
>>
>> Have you talked to the WebKit folks to see what eligibility criteria they 
>>>> plan to use for their version of the feature?
>>>>
>>> Yes. I understand their criteria is also when the service worker is not 
>> running. Please check this comment 
>> <https://github.com/WICG/proposals/issues/155#issuecomment-2873318636>.
>>  
>>
>>>
>>>> -- Dan
>>>>
>>>> ------------------------------
>>>> *From:* Shunya Shishido <sisid...@chromium.org>
>>>> *Sent:* Wednesday, July 23, 2025 12:54 AM
>>>> *To:* blink-dev <blin...@chromium.org>
>>>> *Subject:* [EXTERNAL] [blink-dev] Intent to Ship: 
>>>> ServiceWorkerAutoPreload
>>>>  
>>>> You don't often get email from sisid...@chromium.org. Learn why this 
>>>> is important <https://aka.ms/LearnAboutSenderIdentification>
>>>> Contact emails 
>>>> sisid...@chromium.org
>>>>
>>>> Explainer 
>>>> https://github.com/WICG/service-worker-auto-preload
>>>>
>>>> Specification 
>>>> https://github.com/w3c/ServiceWorker/pull/1756
>>>>
>>>> Summary 
>>>>
>>>> ServiceWorkerAutoPreload is a mode where the browser issues the network 
>>>> request in parallel with the service worker bootstrap, and consumes the 
>>>> network request result inside the fetch handler if the fetch handler 
>>>> returns the response with `respondWith()`. If the fetch handler result is 
>>>> fallback, it passes the network response directly to the browser. 
>>>> ServiceWorkerAutoPreload is defined as an optional browser optimization, 
>>>> which will change the existing service worker behavior. We expect the 
>>>> impact on Enterprise is low, but the temporary enterprise policy called 
>>>> ServiceWorkerAutoPreloadEnabled will be added to control this feature.
>>>>
>>>>
>>>> Blink component 
>>>> Blink>ServiceWorker 
>>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EServiceWorker%22>
>>>>
>>>> TAG review 
>>>> https://github.com/w3ctag/design-reviews/issues/1108 
>>>> https://github.com/w3ctag/design-reviews/issues/963
>>>>
>>>> TAG review status 
>>>> Pending
>>>>
>>>> Risks 
>>>>
>>>>
>>>> Interoperability and Compatibility 
>>>>
>>>> For compatibility risks, the main concern was about how this feature 
>>>> works with the navigation preload API. But we don't think this feature 
>>>> introduces major compatibility issues because this feature respects the 
>>>> navigation preload API, and is not exposed when the navigation preload API 
>>>> is already enabled. The only cost is the server side cost to respond to 
>>>> the 
>>>> network requests, which may not be used if the fetch handler returns a 
>>>> result from the disk cache. This cost can be reduced by applying the 
>>>> feature only when the service worker is not started, or only for websites 
>>>> that meet some criteria e.g. fetch handler always fallback to the network.
>>>>
>>>>
>>>> *Gecko*: No signal (
>>>> https://github.com/mozilla/standards-positions/issues/1036)
>>>>
>>>> *WebKit*: No signal (
>>>> https://github.com/WebKit/standards-positions/issues/359) Although we 
>>>> are still waiting for WebKit's official standard position, we believe they 
>>>> are supportive. A reply on the proposal mentioned that it 'seems inline 
>>>> with what WebKit is implementing,' and a WebKit reviewer has already 
>>>> approved our spec change PR. 
>>>> https://github.com/WICG/proposals/issues/155#issuecomment-2873318636 
>>>> https://github.com/w3c/ServiceWorker/pull/1756
>>>>
>>>> *Web developers*: No signals
>>>>
>>>> *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?*
>>>>
>>>> None
>>>>
>>>>
>>>> Debuggability 
>>>>
>>>> We have a plan to show some info when the preload requests by this 
>>>> feature are triggered on DevTools. It's tracked in crbug.com/344912796
>>>>
>>>>
>>>> Will this feature be supported on all six Blink platforms (Windows, 
>>>> Mac, Linux, ChromeOS, 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
>>>>
>>>> Currently we don't have WPT tests. As this feature is only exposed with 
>>>> heuristics and it doesn't have an API surface, it's not testable on the 
>>>> WPT 
>>>> infrastructure.
>>>>
>>>>
>>>> Flag name on about://flags 
>>>> service-worker-auto-preload
>>>>
>>>> Finch feature name 
>>>> ServiceWorkerAutoPreload
>>>>
>>>> Rollout plan 
>>>> Will ship enabled for all users
>>>>
>>>> Requires code in //chrome? 
>>>> False
>>>>
>>>> Tracking bug 
>>>> https://crbug.com/40278676
>>>>
>>>> Estimated milestones 
>>>>
>>>> Shipping on desktop
>>>> 140
>>>> Origin trial desktop first
>>>> 131
>>>> Origin trial desktop last
>>>> 136
>>>> DevTrial on desktop
>>>> 126
>>>> Shipping on Android
>>>> 140
>>>> Origin trial Android first
>>>> 131
>>>> Origin trial Android last
>>>> 136
>>>> DevTrial on Android
>>>> 126
>>>> Shipping on WebView
>>>> 140
>>>>
>>>>
>>>> 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).*
>>>> None
>>>>
>>>> Link to entry on the Chrome Platform Status 
>>>> https://chromestatus.com/feature/5194817700364288?gate=6249384911306752
>>>>
>>>> Links to previous Intent discussions 
>>>> Intent to Prototype: 
>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGMyg-btkw3n_k0Vr9GgW%2B_c%2BT5K%3D_1_BPFstqAVi0y%3DxxT-pg%40mail.gmail.com
>>>> Intent to Experiment: 
>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGMyg-YF1qRNkBUPGxN-GgDGG3yvqCijZ56QEQYgNA4a9YrfMg%40mail.gmail.com
>>>>
>>>>
>>>> This intent message was generated by Chrome Platform Status 
>>>> <https://chromestatus.com/>.
>>>> --
>>>> 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 visit 
>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGMyg-YGDFiHciHb701OhxBf3QUQbs-11o%2BjY03AAxvrrYmxow%40mail.gmail.com
>>>>  
>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGMyg-YGDFiHciHb701OhxBf3QUQbs-11o%2BjY03AAxvrrYmxow%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+...@chromium.org.
>>>> To view this discussion visit 
>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CH4PR00MB23298ED82DCB351D28A07555C559A%40CH4PR00MB2329.namprd00.prod.outlook.com
>>>>  
>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CH4PR00MB23298ED82DCB351D28A07555C559A%40CH4PR00MB2329.namprd00.prod.outlook.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 visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/7b49cfb0-87df-4417-8f53-9c40ae391ffdn%40chromium.org.

Reply via email to