Andrew Guan on web.dev

Broadcast updates to pages with service workers

2020-12-08T00:00:00Z

In some scenarios the service worker might need to proactively communicate with any of the active tabs it controls to inform of a certain event. Examples include:

Informing the page when a new version of the service worker has been installed, so that the page can show an "Update to refresh" button to the user to access the new functionality immediately.
Letting the user know about a change on cached data that took place on the service worker side, by showing an indication, like: "The app is now ready to work offline", or "New version of the content available".

We'll call these types of use cases where the service worker doesn't need to receive a message from the page to start a communication "broadcast updates". In this guide we'll review different ways of implementing this type of communication between pages and service workers, by using standard browser APIs and the Workbox library.

Production cases #

Tinder #

Tinder PWA uses workbox-window to listen to important service worker lifecycle moments from the page ("installed", "controlled" and "activated"). That way when a new service worker comes into play, it shows an "Update Available" banner, so that they can refresh the PWA and access the latest features:

In the Tinder PWA, the service worker tells the page that a new version is ready, and the page shows users a "Update Available" banner.

Squoosh #

In the Squoosh PWA, when the service worker has cached all of the necessary assets to make it work offline, it sends a message to the page to show a "Ready to work offline" toast, letting the user know about the feature:

In the Squoosh PWA the service worker broadcasts an update to the page when cache is ready, and the page displays "Ready to work offline" toast.

Using Workbox #

Listen to service worker lifecycle events #

workbox-window provides a straightforward interface to listen to important service worker lifecycle events. Under the hood, the library uses client-side APIs like updatefound and statechange and provides higher level event listeners in the workbox-window object, making it easier for the user to consume these events.

The following page code lets you detect every time a new version of the service worker is installed, so you can communicate it to the user:

const wb = new Workbox('/sw.js');

wb.addEventListener('installed', (event) => {
  if (event.isUpdate) {
    // Show "Update App" banner
  }
});

wb.register();

Inform the page of changes in cache data #

The Workbox package workbox-broadcast-update provides a standard way of notifying window clients that a cached response has been updated. This is most commonly used along with the StaleWhileRevalidate strategy.

To broadcast updates add a broadcastUpdate.BroadcastUpdatePlugin to your strategy options in the service worker side:

import {registerRoute} from 'workbox-routing';
import {StaleWhileRevalidate} from 'workbox-strategies';
import {BroadcastUpdatePlugin} from 'workbox-broadcast-update';

registerRoute(
  ({url}) => url.pathname.startsWith('/api/'),
  new StaleWhileRevalidate({
    plugins: [
      new BroadcastUpdatePlugin(),
    ],
  })
);

In your web app, you can listen for these events like so:

navigator.serviceWorker.addEventListener('message', async (event) => {
  // Optional: ensure the message came from workbox-broadcast-update
  if (event.data.meta === 'workbox-broadcast-update') {
    const {cacheName, updatedUrl} = event.data.payload;

    // Do something with cacheName and updatedUrl.
    // For example, get the cached content and update
    // the content on the page.
    const cache = await caches.open(cacheName);
    const updatedResponse = await cache.match(updatedUrl);
    const updatedText = await updatedResponse.text();
  }
});

Using browser APIs #

If the functionality that Workbox provides is not enough for your needs, use the following browser APIs to implement "broadcast updates":

Broadcast Channel API #

The service worker creates a BroadcastChannel object and starts sending messages to it. Any context (e.g. page) interested in receiving these messages can instantiate a BroadcastChannel object and implement a message handler to receive messages.

To inform the page when a new service worker is installed, use the following code:

// Create Broadcast Channel to send messages to the page
const broadcast = new BroadcastChannel('sw-update-channel');

self.addEventListener('install', function (event) {
  // Inform the page every time a new service worker is installed
  broadcast.postMessage({type: 'CRITICAL_SW_UPDATE'});
});

The page listens to these events by subscribing to the sw-update-channel:

// Create Broadcast Channel and listen to messages sent to it
const broadcast = new BroadcastChannel('sw-update-channel');

broadcast.onmessage = (event) => {
  if (event.data && event.data.type === 'CRITICAL_SW_UPDATE') {
    // Show "update to refresh" banner to the user.
  }
};

This is a simple technique, but its limitation is browser support: at the moment of this writing, Safari doesn't support this API.

Client API #

The Client API provides a straightforward way of communicating with multiple clients from the service worker by iterating over an array of Client objects.

Use the following service worker code to send a message to the last focused tab:

// Obtain an array of Window client objects
self.clients.matchAll(options).then(function (clients) {
  if (clients && clients.length) {
    // Respond to last focused tab
    clients[0].postMessage({type: 'MSG_ID'});
  }
});

The page implements a message handler to intercept these messages:

// Listen to messages
navigator.serviceWorker.onmessage = (event) => {
     if (event.data && event.data.type === 'MSG_ID') {
         // Process response
   }
};

Client API is a great option for cases like broadcasting information to multiple active tabs. The API is supported by all major browsers, but not all of its methods are. Check browser support before using it.

Message Channel #

Message Channel requires an initial configuration step, by passing a port from the page to the service worker, to establish a communication channel between them. The page instantiates a MessageChannel object and passes a port to the service worker, via the postMessage() interface:

const messageChannel = new MessageChannel();

// Init port
navigator.serviceWorker.controller.postMessage({type: 'PORT_INITIALIZATION'}, [
  messageChannel.port2,
]);

The page listens to messages by implementing an "onmessage" handler on that port:

// Listen to messages
messageChannel.port1.onmessage = (event) => {
  // Process message
};

The service worker receives the port and saves a reference to it:

// Initialize
let communicationPort;

self.addEventListener('message', (event) => {
  if (event.data && event.data.type === 'PORT_INITIALIZATION') {
    communicationPort = event.ports[0];
  }
});

From that point it can send messages to the page, by calling postMessage() in the reference to the port:

// Communicate
communicationPort.postMessage({type: 'MSG_ID' });

MessageChannel might be more complex to implement, due to the need of initializing ports, but it's supported by all major browsers.

Next steps #

In this guide we explored one particular case of Window to service worker communication: "broadcast updates". The examples explored include listening to important service worker lifecycle events, and communicating to the page about changes in content or cached data. You can think of more interesting use cases where the service worker proactively communicates with the page, without receiving any message previously.

For more patterns of Window and service worker communication check out:

Imperative caching guide: Calling a service worker from the page to cache resources in advance (e.g. in prefetching scenarios).
Two-way communication: Delegating a task to a service worker (e.g. a heavy download), and keeping the page informed on the progress.

Additional resources #

Imperative caching guide

2020-12-08T00:00:00Z

Some websites might need to communicate to the service worker without the need of being informed about the result. Here are some examples:

A page sends the service worker a list of URLs to prefetch, so that, when the user clicks on a link the document or page subresources are already available in the cache, making subsequent navigation much faster.
The page asks the service worker to retrieve and cache a set of top articles, to have them available for offline purposes.

Delegating these types of non-critical tasks to the service worker has the benefit of freeing up the main thread for better handling more pressing tasks such as responding to user interactions.

In this guide we'll explore how to implement a one-way communication technique from the page to the service worker by using standard browser APIs and the Workbox library. We'll call these types of use cases imperative caching.

Production case #

1-800-Flowers.com implemented imperative caching (prefetching) with service workers via postMessage() to prefetch the top items in category pages to speed up subsequent navigation to product detail pages.

They use a mixed approach to decide which items to prefetch:

At page load time they ask the servicer worker to retrieve the JSON data for the top 9 items, and add the resulting response objects to the cache.
For the remaining items, they listen to the mouseover event, so that, when a user moves the cursor on top of an item, they can trigger a fetch for the resource on "demand".

They use the Cache API to store JSON responses:

Prefetching JSON product data from product listing pages in 1-800Flowers.com.

When the user clicks on an item, the JSON data associated with it can be picked up from the cache, without the need of going to the network, making the navigation faster.

Using Workbox #

Workbox provides an easy way to send messages to a service worker, via the workbox-window package, a set of modules that are intended to run in the window context. They're a complement to the other Workbox packages that run in the service worker.

To communicate the page with the service worker, first obtain a Workbox object reference to the registered service worker:

const wb = new Workbox('/sw.js');
wb.register();

Then you can directly send the message declaratively, without the hassle of the getting the registration, checking for activation, or thinking about the underlying communication API:

wb.messageSW({"type": "PREFETCH", "payload": {"urls": ["/data1.json", "data2.json"]}}); });

The service worker implements a message handler to listen to these messages. It can optionally return a response, although, in cases like these, it's not necessary:

self.addEventListener('message', (event) => {
  if (event.data && event.data.type === 'PREFETCH') {
    // do something
  }
});

Using browser APIs #

If the Workbox library is not enough for your needs, here is how you can implement window to service worker communication, using browser APIs.

The postMessage API can be used to establish a one-way communication mechanism from the page to the service worker.

The page calls postMessage() on the service worker interface:

navigator.serviceWorker.controller.postMessage({
  type: 'MSG_ID',
  payload: 'some data to perform the task',
});

The service worker implements a message handler to listen to these messages.

self.addEventListener('message', (event) => {
  if (event.data && event.data.type === MSG_ID) {
    // do something
  }
});

The {type : 'MSG_ID'} attribute is not absolutely required, but it is one way to allow the page to send different types of instructions to the service worker (that is, 'to prefetch' vs. 'to clear storage'). The service worker can branch into different execution paths based on this flag.

If the operation was successful, the user will be able to get the benefits from it but, if not, it won't alter the main user flow. For example, when 1-800-Flowers.com attempts to precache, the page doesn't need to know whether the service worker succeeded. If it does, then the user will enjoy a faster navigation. If it doesn't the page still needs to navigate to the new page. It's just going to take a little longer.

A simple prefetching example #

One of the most common applications of imperative caching is prefetching, meaning fetching resources for a given URL, before the user moves to it, in order to speed up navigation.

There are different ways of implementing prefetching in sites:

Using Link prefetch tags in pages: resources are kept in the browser cache for five minutes, after which the normal Cache-Control rules for the resource apply.
Complementing the previous technique with a runtime caching strategy in the service worker to extend the lifetime of the prefetch resource beyond this limit.

For relatively simple prefetching scenarios, like prefetching documents, or specific assets (JS, CSS, etc.), those techniques are the best approach.

If additional logic is required, for example, parsing the prefetch resource (a JSON file or page) in order to fetch its internal URLs, it's more appropriate to delegate this task entirely to the service worker.

Delegating these types of operations to the service worker has the following advantages:

Offloading the heavy lifting of fetching and post-fetch processing (which will be introduced later) to a secondary thread. By doing this, it frees the main thread to handle more important tasks such as responding to user interactions.
Allowing multiple clients (e.g. tabs) to reuse a common functionality, and even calling the service simultaneously without blocking the main thread.

Prefetch product detail pages #

First use postMessage() on the service worker interface and pass an array of URLs to cache:

navigator.serviceWorker.controller.postMessage({
  type: 'PREFETCH',
  payload: {
    urls: [
      'www.exmaple.com/apis/data_1.json',
      'www.exmaple.com/apis/data_2.json',
    ],
  },
});

In the service worker, implement a message handler to intercept and process messages sent by any active tab:

addEventListener('message', (event) => {
  let data = event.data;
  if (data && data.type === 'PREFETCH') {
    let urls = data.payload.urls;
    for (let i in urls) {
      fetchAsync(urls[i]);
    }
  }
});

In the previous code we introduced a small helper function called fetchAsync() to iterate on the array of URLs and issue a fetch request for each of them:

async function fetchAsync(url) {
  // await response of fetch call
  let prefetched = await fetch(url);
  // (optionally) cache resources in the service worker storage
}

When the response is obtained you can rely on the caching headers of the resource. In many cases though, like in product detail pages, resources are not cached (which means, they have a Cache-control header of no-cache). In cases like these you can override this behavior, by storing the fetched resource in the service worker cache. This has the added benefit of allowing the file to be served in offline scenarios.

Beyond JSON data #

Once the JSON data is fetched from a server endpoint, it often contains other URLs that are also worth prefetching, such as an image or other endpoint data that are associated with this first-level data.

Let's say that in our example, the JSON data returned is the information of a grocery shopping site:

{
  "productName": "banana",
  "productPic": "https://cdn.example.com/product_images/banana.jpeg",
  "unitPrice": "1.99"
 }

Modify the fetchAsync() code to iterate over the list of products and cache the hero image for each of them:

async function fetchAsync(url, postProcess) {
  // await response of fetch call
  let prefetched = await fetch(url);

  //(optionally) cache resource in the service worker cache

  // carry out the post fetch process if supplied
  if (postProcess) {
    await postProcess(prefetched);
  }
}

async function postProcess(prefetched) {
  let productJson = await prefetched.json();
  if (productJson && productJson.product_pic) {
    fetchAsync(productJson.product_pic);
  }
}

You can add some exception handling around this code for situations like 404s. But the beauty of using a service worker to prefetch is that it can fail without much consequence to the page and the main thread. You may also have more elaborate logic in the post-processing of the prefetched content, making it more flexible and decoupled with the data it's handling. The sky's the limit.

Conclusion #

In this article, we covered a common use case of one-way communication between page and service worker: imperative caching. The examples discussed are only meant for demonstrating one way of using this pattern and the same approach can be applied to other use cases as well, for example, caching top articles on demand for offline consumption, bookmarking, and others.

For more patterns of page and service worker communication, check out:

Broadcast updates: Calling the page from the service worker to inform about important updates (e.g. a new version of the webapp is available).
Two-way communication: Delegating a task to a service worker (e.g. a heavy download), and keeping the page informed on the progress.

Two-way communication with service workers

2020-12-08T00:00:00Z

In some cases, a web app might need to establish a two-way communication channel between the page and the service worker.

For example: in a podcast PWA one could build a feature to let the user download episodes for offline consumption and allow the service worker to keep the page regularly informed about the progress, so the main thread can update the UI.

In this guide we'll explore the different ways of implementing a two-way communication between the Window and service worker context, by exploring different APIs, the Workbox library, as well as some advanced cases.

Using Workbox #

workbox-window is a set of modules of the Workbox library that are intended to run in the window context. The Workbox class provides a messageSW() method to send a message to the instance's registered service worker and await a response.

The following page code creates a new Workbox instance and sends a message to the service worker to obtain its version:

const wb = new Workbox('/sw.js');
wb.register();

const swVersion = await wb.messageSW({type: 'GET_VERSION'});
console.log('Service Worker version:', swVersion);

The service worker implements a message listener on the other end, and responds to the registered service worker:

const SW_VERSION = '1.0.0';

self.addEventListener('message', (event) => {
  if (event.data.type === 'GET_VERSION') {
    event.ports[0].postMessage(SW_VERSION);
  }
});

Under the hood the library uses a browser API that we'll review in the next section: Message Channel, but abstracts many implementation details, making it easier to use, while leveraging the wide browser support this API has.

Using Browser APIs #

If the Workbox library is not enough for your needs, there are several lower-level APIs available to implement "two-way" communication between pages and service workers. They have some similarities and differences:

Similarities:

In all cases the communication starts on one end via the postMessage() interface and is received on the other end by implementing a message handler.
In practice, all the available APIs allow us to implement the same use cases, but some of them might simplify development in some scenarios.

Differences:

They have different ways of identifying the other side of the communication: some of them use an explicit reference to the other context, while others can communicate implicitly via a proxy object instantiated on each side.
Browser support varies among them.

Broadcast Channel API #

Browser support

Chrome 54, Supported 54
Firefox 38, Supported 38
Edge 79, Supported 79
Safari 15.4, Supported 15.4

Source

The Broadcast Channel API allows basic communication between browsing contexts via BroadcastChannel objects.

To implement it, first, each context has to instantiate a BroadcastChannel object with the same ID and send and receive messages from it:

const broadcast = new BroadcastChannel('channel-123');

The BroadcastChannel object exposes a postMessage() interface to send a message to any listening context:

//send message
broadcast.postMessage({ type: 'MSG_ID', });

Any browser context can listen to messages via the onmessage method of the BroadcastChannel object:

//listen to messages
broadcast.onmessage = (event) => {
  if (event.data && event.data.type === 'MSG_ID') {
    //process message...
  }
};

As seen, there's no explicit reference to a particular context, so there's no need of obtaining a reference first to the service worker or any particular client.

The disadvantage is that, at the moment of this writing, the API has support from Chrome, Firefox and Edge, but other browsers, like Safari, don't support it yet.

Client API #

Browser support

Chrome 40, Supported 40
Firefox 44, Supported 44
Edge 17, Supported 17
Safari 11.1, Supported 11.1

Source

The Client API allows you to obtain a reference to all the WindowClient objects representing the active tabs that the service worker is controlling.

Since the page is controlled by a single service worker, it listens to and sends messages to the active service worker directly via the serviceWorker interface:

//send message
navigator.serviceWorker.controller.postMessage({
  type: 'MSG_ID',
});

//listen to messages
navigator.serviceWorker.onmessage = (event) => {
  if (event.data && event.data.type === 'MSG_ID') {
    //process response
  }
};

Similarly, the service worker listens to messages by implementing an onmessage listener:

//listen to messages
self.addEventListener('message', (event) => {
  if (event.data && event.data.type === 'MSG_ID') {
    //Process message
  }
});

To communicate back with any of its clients, the service worker obtains an array of WindowClient objects by executing methods such as Clients.matchAll() and Clients.get(). Then it can postMessage() any of them:

//Obtain an array of Window client objects
self.clients.matchAll(options).then(function (clients) {
  if (clients && clients.length) {
    //Respond to last focused tab
    clients[0].postMessage({type: 'MSG_ID'});
  }
});

Client API is a good option to communicate easily with all the active tabs from a service worker in a relatively straightforward way. The API is supported by all major browsers, but not all its methods might be available, so make sure to check browser support before implementing it in your site.

Message Channel #

Browser support

Chrome 2, Supported 2
Firefox 41, Supported 41
Edge 12, Supported 12
Safari 5, Supported 5

Source

Message Channel requires defining and passing a port from one context to another to establish a two-way communication channel.

To initialize the channel, the page instantiates a MessageChannel object and uses it to send a port to the registered service worker. The page also implements an onmessage listener on it to receive messages from the other context:

const messageChannel = new MessageChannel();

//Init port
navigator.serviceWorker.controller.postMessage({type: 'PORT_INITIALIZATION'}, [
  messageChannel.port2,
]);

//Listen to messages
messageChannel.port1.onmessage = (event) => {
  // Process message
};

The service worker receives the port, saves a reference to it and uses it to send a message to the other side:

let communicationPort;

//Save reference to port
self.addEventListener('message', (event) => {
  if (event.data && event.data.type === 'PORT_INITIALIZATION') {
    communicationPort = event.ports[0];
  }
});

//Send messages
communicationPort.postMessage({type: 'MSG_ID'});

MessageChannel is currently supported by all major browsers.

Advanced APIs: Background Sync and Background Fetch #

In this guide we explored ways of implementing two-way communication techniques, for relatively simple cases, like passing a string message describing the operation to perform, or a list of URLs to cache from one context to the other. In this section we'll explore two APIs to handle specific scenarios: lack of connectivity and long downloads.

Background Sync #

Browser support

Chrome 49, Supported 49
Firefox, Not supported
Edge 79, Supported 79
Safari, Not supported

Source

A chat app might want to make sure that messages are never lost due to bad connectivity. The Background Sync API lets you defer actions to be retried when the user has stable connectivity. This is useful for ensuring that whatever the user wants to send, is actually sent.

Instead of the postMessage() interface, the page registers a sync:

navigator.serviceWorker.ready.then(function (swRegistration) {
  return swRegistration.sync.register('myFirstSync');
});

The service worker then listens for the sync event to process the message:

self.addEventListener('sync', function (event) {
  if (event.tag == 'myFirstSync') {
    event.waitUntil(doSomeStuff());
  }
});

The function doSomeStuff() should return a promise indicating the success/failure of whatever it's trying to do. If it fulfills, the sync is complete. If it fails, another sync will be scheduled to retry. Retry syncs also wait for connectivity, and employ an exponential back-off.

Once the operation has been performed, the service worker can then communicate back with the page to update the UI, by using any of the communication APIs explored earlier.

Google search uses Background Sync to persist failed queries due to bad connectivity, and retry them later when the user is online. Once the operation is performed, they communicate the result to the user via a web push notification:

Background Fetch #

Browser support

Chrome 74, Supported 74
Firefox, Not supported
Edge 79, Supported 79
Safari, Not supported

Source

For relatively short bits of work like sending a message, or a list of URLs to cache, the options explored so far are a good choice. If the task takes too long the browser will kill the service worker, otherwise it's a risk to the user's privacy and battery.

The Background Fetch API allows you to offload a long task to a service worker, like downloading movies, podcasts, or levels of a game.

To communicate to the service worker from the page, use backgroundFetch.fetch, instead of postMessage():

navigator.serviceWorker.ready.then(async (swReg) => {
  const bgFetch = await swReg.backgroundFetch.fetch(
    'my-fetch',
    ['/ep-5.mp3', 'ep-5-artwork.jpg'],
    {
      title: 'Episode 5: Interesting things.',
      icons: [
        {
          sizes: '300x300',
          src: '/ep-5-icon.png',
          type: 'image/png',
        },
      ],
      downloadTotal: 60 * 1024 * 1024,
    },
  );
});

The BackgroundFetchRegistration object allows the page listen to the progress event to follow the progress of the download:

bgFetch.addEventListener('progress', () => {
  // If we didn't provide a total, we can't provide a %.
  if (!bgFetch.downloadTotal) return;

  const percent = Math.round(
    (bgFetch.downloaded / bgFetch.downloadTotal) * 100,
  );
  console.log(`Download progress: ${percent}%`);
});

The UI is updated to indicate the progress of a download (left). Thanks to service workers, the operation can continue running when all tabs have been closed (right).

Next steps #

In this guide we explored the most general case of communication between page and service workers (bidirectional communication).

Many times, one might need only one context to communicate with the other, without receiving a response. Check out the following guides for guidance how to implement unidirectional techniques in your pages from and to the service worker, along with use cases and production examples:

Imperative caching guide: Calling a service worker from the page to cache resources in advance (e.g. in prefetching scenarios).
Broadcast updates: Calling the page from the service worker to inform about important updates (e.g. a new version of the webapp is available).

Workers overview

2020-12-08T00:00:00Z

This overview explains how web workers and service workers can improve the performance of your website, and when to use a web worker versus a service worker. Check out the rest of this series for specific patterns of window and service worker communication.

How workers can improve your website #

The browser uses a single thread (the main thread) to run all the JavaScript in a web page, as well as to perform tasks like rendering the page and performing garbage collection. Running excessive JavaScript code can block the main thread, delaying the browser from performing these tasks and leading to a poor user experience.

In iOS/Android application development, a common pattern to ensure that the app's main thread remains free to respond to user events is to offload operations to additional threads. In fact, in the latest versions of Android, blocking the main thread for too long leads to an app crash.

On the web, JavaScript was designed around the concept of a single thread, and lacks capabilities needed to implement a multithreading model like the one apps have, like shared memory.

Despite these limitations, a similar pattern can be achieved in the web by using workers to run scripts in background threads, allowing them to perform tasks without interfering with the main thread. Workers are an entire JavaScript scope running on a separate thread, without any shared memory.

In this post you'll learn about two different types of workers (web workers and service workers), their similarities and differences, and the most common patterns for using them in production websites.

Web workers and service workers #

Similarities #

Web workers and service workers are two types of workers available to websites. They have some things in common:

Both run in a secondary thread, allowing JavaScript code to execute without blocking the main thread and the user interface.
They don't have access to the Window and Document objects, so they can't interact with the DOM directly, and they have limited access to browser APIs.

Differences #

One might think that most things that can be delegated to a web worker can be done in a service worker and vice versa, but there are important differences between them:

Unlike web workers, service workers allow you to intercept network requests (via the fetch event) and to listen for Push API events in the background (via the push event).
A page can spawn multiple web workers, but a single service worker controls all the active tabs under the scope it was registered with.
The lifespan of the web worker is tightly coupled to the tab it belongs to, while the service worker's lifecycle is independent of it. For that reason, closing the tab where a web worker is running will terminate it, while a service worker can continue running in the background, even when the site doesn't have any active tabs open.

Use cases #

The differences between both types of workers suggest in which situations one might want to use one or the other:

Use cases for web workers are more commonly related to offloading work (like heavy computations) to a secondary thread, to avoid blocking the UI.

Example: the team that built the videogame PROXX wanted to leave the main thread as free as possible to take care of user input and animations. To achieve that, they used web workers to run the game logic and state maintenance on a separate thread.

Service workers tasks are generally more related to acting as a network proxy, handling background tasks, and things like caching and offline.

Example: In a podcast PWA, one might want to allow users to download complete episodes to listen to them while offline. A service worker, and, in particular, the Background Fetch API can be used to that end. That way, if the user closes the tab while the episode is downloading, the task doesn't have to be interrupted.

The UI is updated to indicate the progress of a download (left). Thanks to service workers, the operation can continue running when all tabs have been closed (right).

Tools and libraries #

Window and worker communication can be implemented by using different lower level APIs. Fortunately, there are libraries that abstract this process, taking care of the most common use cases. In this section, we'll cover two of them that take care of window to web workers and service workers respectively: Comlink and Workbox.

Comlink #

Comlink is a small (1.6k) RPC library that takes care of many underlying details when building websites that use Web Workers. It has been used in websites like PROXX and Squoosh. A summary of its motivations and code samples can be found here.

Workbox #

Workbox is a popular library to build websites that use service workers. It packages a set of best practices around things like caching, offline, background synchronization, etc. The workbox-window module provides a convenient way to exchange messages between the service worker and the page.

Next steps #

The rest of this series focuses on patterns for window and service worker communication:

Imperative caching guide: Calling a service worker from the page to cache resources in advance (e.g. in prefetching scenarios).
Broadcast updates: Calling the page from the service worker to inform about important updates (e.g. a new version of the website is available).
Two-way communication: Delegating a task to a service worker (e.g. a heavy download), and keeping the page informed on the progress.

For patterns of window and web worker communication check out: Use web workers to run JavaScript off the browser's main thread.