Back in 2015, Google announced a new concept – Progressive Apps (PWA). This is a new format of combining the best parts of the and native apps. At the heart of PWA is the use of Service Workers (SW). They act as a proxy server that is located between the application in the browser and the network. SWs are intended to intercept network requests, take appropriate steps based on the network availability, update data on the server, and ensure effective of web applications in the offline mode. (Those who are familiar with SWs and want to proceed directly to the functionality that 5 has brought to work with them, can skip the first part of this tutorial.)

SWs are in some ways similar to Web Workers, but they’re not regarded as the successor of an Worker class. SWs have their own logic of registration and an independent life cycle. You can register SWs in the following way:


Considering that the browser is still far from being perfect, it’s worth checking the availability of SW functionality.

Support table for Service Worker

Support table for Service Worker

The lifecycle of the SW involves several steps. After you’ve registered the SW, the browser can try to install it and activate it on the page.

Lifecycle of the Service Worker

The event “install” occurs after the successful installation. This event is used mainly to fill the browser’s cache with the resources necessary for the successful launch in the offline mode. In this case you use the new API repository of Service Worker, which is global for all SWs and allows to store the results of queries using the queries themselves as a the key for obtaining them. This API works in the same way as the standard browser cache, but only for your domain. The data in cache is stored until you decide to delete it.

service-worker.js - 01

After the successful installation, the SW is activated. This aspect is not very important for the initial installation and activation of the SW, but at the same time it plays a significant when the worker is being updated. For example, a Network-First cache update (discussed below). You can also handle the event “activate.” You’ll usually use this in case you need to perform actions that would violate the work of the previous version of workers if they’re still working with the old cache. You’ll also find this event effective for deleting unnecessary data and freeing disk space because each browser has strict limits regarding the size of the cache storage that is available only for use by SWs.

service-worker.js - 02

What does Service Worker allow? Just like any other Web Worker, it can react to events sent from the main thread of execution by means of the messages API.

self.onmessage = (event) => {
    let result = someCalculations(;

You can also hang handlers on fetch events while intercepting network requests and on push events for processing push messages from server.

service-worker.js - 03

When processing requests using SW, you can use a number of different strategies. The most are called Cache First and Network First.

Source link
thanks you RSS link


Please enter your comment!
Please enter your name here