Describe the challenge or problem on the web you are proposing we address.
ServiceWorker is a popular API involved in about 15% of page loads. This API offers many advanced features such as fetch handling, push notification, background sync, etc. The ServiceWorker’s fetch handling capability allows developers to intercept and control the resource fetch requests via “fetch” event handler. This enables web apps to be reliable even while offline and delivers faster loading experiences by using its own CacheStorage. However, the cost of starting up a ServiceWorker can be non-negligible. ServiceWorker fetch handlers are invoked during the critical path for navigation and subresource loading. Developers are sometimes using fetch handlers to speed up page loading but the fetch handlers may slow down page loading if the ServiceWorker is not running, the cache access is slower than network (e.g., 5G network), or the resource was not cached. In the worst case, it can take up to hundreds of milliseconds to bootstrap the ServiceWorker itself and process fetch event handlers.
Fetch handlers are used for various reasons but there are many cases where developers use them with the intention of serving resources faster than the network. To fulfill their intention, this document proposes the introduction of “ServiceWorkerAutoPreload”, a new loading strategy for ServiceWorker.
ServiceWorkerAutoPreload is a mode where the browser issues a network request (i.e. a regular request which may result in a HTTP cache hit or an actual fetch) in parallel with the ServiceWorker bootstrap, and consumes the network request result inside the fetch handler.
This new behavior introduced by ServiceWorkerAutoPreload acts something like “auto NavigationPreload”. NavigationPreload starts a dedicated network request and the fetch handler at the same time, and resolves it as event.preloadResponse inside the fetch handler. Similarly ServiceWorkerAutoPreload starts those two processes at the same time, but the network request is resolved with fetch(event.request) inside the fetch handler. Unlike NavigationPreload, ServiceWorkerAutoPreload doesn’t require any additional code changes.
ServiceWorkerAutoPreload also uses its response when the browser issues a fallback network request. Without ServiceWorkerAutoPreload, the browser issues a new network request after receiving the fallback result from the fetch handler.
Introduction
Describe the challenge or problem on the web you are proposing we address.
ServiceWorker is a popular API involved in about 15% of page loads. This API offers many advanced features such as fetch handling, push notification, background sync, etc. The ServiceWorker’s fetch handling capability allows developers to intercept and control the resource fetch requests via “fetch” event handler. This enables web apps to be reliable even while offline and delivers faster loading experiences by using its own CacheStorage. However, the cost of starting up a ServiceWorker can be non-negligible. ServiceWorker fetch handlers are invoked during the critical path for navigation and subresource loading. Developers are sometimes using fetch handlers to speed up page loading but the fetch handlers may slow down page loading if the ServiceWorker is not running, the cache access is slower than network (e.g., 5G network), or the resource was not cached. In the worst case, it can take up to hundreds of milliseconds to bootstrap the ServiceWorker itself and process fetch event handlers.
Fetch handlers are used for various reasons but there are many cases where developers use them with the intention of serving resources faster than the network. To fulfill their intention, this document proposes the introduction of “ServiceWorkerAutoPreload”, a new loading strategy for ServiceWorker.
ServiceWorkerAutoPreload is a mode where the browser issues a network request (i.e. a regular request which may result in a HTTP cache hit or an actual fetch) in parallel with the ServiceWorker bootstrap, and consumes the network request result inside the fetch handler.
This new behavior introduced by ServiceWorkerAutoPreload acts something like “auto NavigationPreload”. NavigationPreload starts a dedicated network request and the fetch handler at the same time, and resolves it as event.preloadResponse inside the fetch handler. Similarly ServiceWorkerAutoPreload starts those two processes at the same time, but the network request is resolved with fetch(event.request) inside the fetch handler. Unlike NavigationPreload, ServiceWorkerAutoPreload doesn’t require any additional code changes.
ServiceWorkerAutoPreload also uses its response when the browser issues a fallback network request. Without ServiceWorkerAutoPreload, the browser issues a new network request after receiving the fallback result from the fetch handler.
Read the complete Explainer.
Feedback (Choose One)
I welcome feedback in this thread, but encourage you to file bugs against the Explainer.