This blog post covers service worker basics and different caching strategies with service workers and Workbox.
Service worker
A service worker is a network proxy that can intercept and handle requests and cache or retrieve resources from the cache. It is a script running in the background, separately from the main browser thread.
Lifecycle
Registration
Registration can happen after the page is loaded. Browser support and HTTPS are the main prerequisites.
if ('serviceWorker' in navigator) {
window.addEventListener('load', () => {
navigator.serviceWorker.register('/service-worker.js')
.then(() => console.log('Service worker is registered!'))
.catch(() => console.error('Service worker registration failed'));
});
}
Installation
The install
event is emitted when a new or modified service worker file exists. Assets can be precached during the mentioned event.
self.addEventListener('install', (event) => {
// cache assets
});
Waiting
After successful installation, the updated service worker delays activating until the existing service worker no longer controls clients.
Activation
The activate
event is dispatched once the old service worker is gone and a new one can control clients.
The skipWaiting
method during the install
event ensures that any new version will become activated immediately. Use it with clientsClaim
to ensure the new service worker controls all active clients directly.
The outdated cache can be deleted during the mentioned event.
self.addEventListener('activate', (event) => {
// clear outdated cache
});
Workbox
Workbox is a set of libraries that makes building offline progressive web apps easier. It contains libraries for precaching, runtime caching, and caching strategies, to name a few.
importScripts('https://storage.googleapis.com/workbox-cdn/releases/6.5.4/workbox-sw.js');
const {
cacheableResponse: { CacheableResponsePlugin },
expiration: { ExpirationPlugin },
routing: { registerRoute },
strategies: { CacheFirst, StaleWhileRevalidate },
} = workbox;
Caching
Caching ensures the app loads as efficiently as possible for repeat visitors. Precaching and runtime caching will be covered briefly.
Precaching means saving files to the cache during the service worker installation and allowing it to serve cached files without network access.
Runtime caching refers to gradually adding responses to a cache, and it allows serving cached files by combining cache and network in multiple ways.
Common runtime caching strategies
Stale-while-revalidate
With the stale-while-revalidate strategy, the cached response is retrieved if available. The service worker will also send a network request to get the latest version, and the response will update the cache.
If the cached response is unavailable, the network response will be passed back to the app.
Use this strategy when showing immediately the resource is vital, even if it's an older value.
registerRoute(
({ request }) => request.mode === 'navigate',
new StaleWhileRevalidate({
cacheName: 'pages',
plugins: [
new CacheableResponsePlugin({
statuses: [0, 200],
}),
],
}),
);
Cache-first
With the cache-first strategy, the cached response is retrieved if available, and the network won't be used.
If the cached response is not available, the response is retrieved from the network. In that case, the network response will update the cache.
Use this strategy for assets that are unlikely to change (e.g., font files, images).
registerRoute(
({ request }) => request.destination === 'image',
new CacheFirst({
cacheName: 'images',
plugins: [
new CacheableResponsePlugin({
statuses: [0, 200],
}),
new ExpirationPlugin({
maxEntries,
maxAgeSeconds,
}),
],
}),
);
Network-first
With a network-first strategy, the service worker tries to fetch the response from the network, and if it is successful, the cache will be updated with the response.
If the network response fails, the cached response will be used.
Use this strategy for resources whose newest update is essential but still needed offline.
Cache-only
Use this strategy for precached files (e.g., default offline page).
Network-only
Use this strategy for non-GET requests (e.g., forms).
Demo
The demo with the mentioned examples for the Progressive Web App is available here.
Top comments (0)