-
Notifications
You must be signed in to change notification settings - Fork 0
Description
As we announced in the Intent to Experiment email in blink-dev, we've running the ServiceWorkerAutoPreload experiment since Chrome 131.
Two experimental groups were tested:
- ServiceWorkerAutoPreload without any criteria. As explained in the explainer, our plan is to enable ServiceWorkerAutoPreload when sites meet an criteria. We used this group to know the potential upper-bound impact by ServiceWorkerAutoPreload (the criteria having 100% coverage), and don't have a plan to ship it as it is.
- Enabling it only when the service worker is not running at navigation timing. This is a potential criteria that we'd like to enable ServiceWorkerAutoPreload. When the SW is not running, we enable ServiceWorkerAutoPreload, but when the SW is not running, we don't enable the feature.
The experiment ran for a month on Stable, both groups showed positive impacts on multiple loading performance metrics on Android, such as LCP in Service Worker-controlled pages. The second group, which enabled ServiceWorkerAutoPreload only when the SW was not running, achieved approximately 80% of the performance improvement observed in the first group, which represented the maximum potential impact by enabling the feature without any criteria.
Based on the experiment result, we'd like to standardize this behavior as an optional optimization that the browser can apply at its choosing. Because preload requests issued by ServiceWorkerAutoPreload could be observable via the server as additional requests, while ServiceWorkerAutoPreload gives performance benefits as written in the rollout plan section.
w3c/ServiceWorker#1756 will be the potential spec change to support ServiceWorkerAutoPreload.