This is Chromium's implementation of service workers. See the Service Worker specification.
Service worker storage consists of the following.
Code pointers include ServiceWorkerDatabase and ServiceWorkerStorage.
The related Cache Storage API uses a disk_cache instance using the “simple” implementation, located at ${DIR_USER_DATA}/Service Worker/CacheStorage. This location was chosen because the Cache Storage API is currently defined in the Service Worker specification, but it can be used independently of service workers.
For incognito windows, everything is in-memory.
Service workers storage lasts indefinitely, i.e, there is no periodic deletion of old but still installed service workers. Installed service workers are only evicted by the Quota Manager (or user action). The Quota Manager controls several web platform APIs, including sandboxed filesystem, WebSQL, appcache, IndexedDB, cache storage, service worker (registration and scripts), and background fetch.
The Quota Manager starts eviction when one of the following conditions is true (as of August 2018):
When eviction starts, origins are purged on an LRU basis until the triggering condition no longer applies. Purging an origin deletes its storage completely.
Note that Quota Manager eviction is independent of HTTP cache eviction. The HTTP cache is typically much smaller than the storage under the control of the Quota Manager, and it likely uses a simple non-origin-based LRU algorithm.
Blink has a UseCounter mechanism intended to measure the percentage of page loads on the web that used a given feature. Service workers complicate this measurement because a feature use in a service worker potentially affects many page loads, including ones in the future.
Therefore, service workers integrate with the UseCounter mechanism as follows:
For more details and rationale, see Design of UseCounter for workers and crbug 376039.
Code pointers include:
We monitor service worker performance with real-world metrics (UMA) and performance benchmarks.
The UMA data is internal-only. Key metrics include:
Page load metrics for service worker controlled loads:
Service worker startup time and breakdown:
Fetch event handling:
TODO(falken, bashi): Add a list of the milestones of startup and fetch event handling.
We run a limited number of Telemetry benchmark tests for service worker. These tests are part of the Loading benchmarks, as the “pwa” tests inside the “loading.mobile” suite. The tests do not run on desktop machines (loading.desktop) due to resource constraints.
See a quick dashboard of these test results. You can also run the benchmarks locally:
# Run benchmark on `FlipKart` $ tools/perf/run_benchmark --browser=android-chromium loading.mobile --story-filter='FlipKart' # Run benchmark on `FlipKart` with cache_temperature = cold $ tools/perf/run_benchmark --browser=android-chromium loading.mobile --story-filter='FlipKart_cold'
TODO(falken): Merge this with loading.md and cache_temperature.py documentation.
The PWA tests load a page multiple times. Each time has a different “cache temperature”. These temperatures have special significance for service worker controlled page loads:
Service workers are terminated between loads in order to include service worker startup as part of the performance test.
Code links and resources: