How does JavaScript work: Service Workers, their lifecycle and use cases

This is series #11 devoted to exploring JavaScript and its building components. Along the way of identifying and describing the core elements, we also shared some rules of thumb we used to build SessionStack, a JavaScript application that utilizes powerful and high-performance features to help users view and reproduce flaws in their Web applications in real time.

If you missed the previous chapters, you can find them here:

• How JavaScript works: An Overview of the engine, runtime, and Call stack (translated)

• Inside Google’s V8 engine + 5 tips on how to write optimized code

• How JavaScript works: Memory Management and How to Handle four common Memory Leaks (translated)

• The event loop and the rise of Async programming + 5 ways to better coding with async/await

• Deep dive into WebSockets and HTTP/2 with SSE + how to pick the right path

• A comparison with WebAssembly + why in certain cases it’s better to use it over JavaScript

• The building blocks of Web Workers + 5 cases when you should use them

As you probably already know, progressive Web apps are only going to grow in popularity because they aim to streamline the Web application user experience and create a native app-like experience rather than the look and feel of a browser.

One of the main requirements for building progressive Web applications is to make them very reliable for networking and loading – it can be used for uncertain or non-existent network conditions.

In this article, we’ll take a closer look at Service Workers: how they work and what you should care about. Finally, we listed some of the Service Workers features you should take advantage of and shared our team’s experience in the SessionStack.

The life cycle of a Service worker is completely independent of your Web page. It consists of the following steps:

• download
• The installation
• The activation

To install a Service Worker for your Web application, you must first register it, which you can do in JavaScript code. When a Service Worker is registered, it prompts the browser to start the Service Worker installation step in the background.

By registering the Service Worker, you can tell the browser where your Service Worker JavaScript files are. Let’s look at the following code:

if ('serviceWorker' in navigator) {
  window.addEventListener('load', function() {
    navigator.serviceWorker.register('/sw.js').then(function(registration) {
      // Registration was successful
      console.log('ServiceWorker registration successful');
    }, function(err) {
      // Registration failed
      console.log('ServiceWorker registration failed: ', err);
    });
  });
}Copy the code

This code checks whether the Service Worker API is supported in the current environment. If so, register the /sw.js Service Worker.

You can call the register() method every time the page loads without worrying – the browser will determine if the Service Worker is registered and will handle it correctly.

An important detail of the register() method is the location of the Service Worker file. In this case, you can see that the Service Worker file is located at the root of the domain. This means that the scope of the Service Worker will be the entire source. In other words, the Service Worker will receive fetch events for everything in the domain (which we’ll discuss later). If we register the Service Worker file in /example/sw.js, the Service Worker will only see the URL as /example/ (i.e. /example/page1/, /example/page2/) page fetch event.

During the installation phase, it is a good idea to load and cache some static resources. After the resources are successfully cached, the Service Worker installation is complete. If not (load failed) – Service Worker will retry. Once installed, you will know that static resources are in the cache.

Questions about whether registration needs to happen after the loading event. This is not required, but it is definitely recommended.

Why is that? Let’s consider the first time a user accesses your web application. There is currently no Service Worker, and the browser cannot know in advance whether there will be a Service Worker that will eventually be installed. If a Service Worker is installed, the browser needs to spend extra CPU and memory for this extra thread, otherwise the browser will spend rendering the page.

On top of that, if you just install a Service Worker on your page, you risk lazy loading and rendering — rather than making the page available to your users as quickly as possible.

Note that this is important only for the first time you visit the page. Subsequent page access is not affected by Service Worker installation. Once the Service Worker is activated the first time a page is accessed, it can handle load/cache events for subsequent access to your Web application. This all makes sense, as it requires being prepared to handle limited network connections.

This is the part that really needs to be dealt with. You’ll see here how requests are intercepted and returned to the created cache (or newly created request).

After the Service Worker is successfully installed, the Service Worker receives a FETCH event when the user browses another page or refreshes the current page. The following example shows how to return a cached resource or perform a new request to cache the result:

self.addEventListener('fetch', function(event) { event.respondWith( // This method looks at the request and // finds any cached results from any of the  // caches that the Service Worker has created. caches.match(event.request) .then(function(response) { // If a cache is hit, we can return thre response. if (response) { return response; } // Clone the request. A request is a stream and // can only be consumed once. Since we are consuming this // once by cache and once by the browser for fetch, we need // to clone the request. var fetchRequest = event.request.clone(); // A cache hasn't been hit so we need to perform a fetch, // which makes a network request and returns the data if // anything can be retrieved from the network. return fetch(fetchRequest).then( function(response) { // Check if we received a valid response if(! response || response.status ! == 200 || response.type ! == 'basic') { return response; } // Cloning the response since it's a stream as well. // Because we want the browser to consume the response // as well  as the cache consuming the response, we need // to clone it so we have two streams. var responseToCache = response.clone(); caches.open(CACHE_NAME) .then(function(cache) { // Add the request to the cache for future queries. cache.put(event.request, responseToCache); }); return response; }); })); });Copy the code

What happens in a NUTSHELL:

• Event.respondwith () will determine how to respond to the FETCH event. We’ll pass a promise from caches.match() to listen for the request and see if there’s a hit in the cache.
• If the cache exists, then the response is sent.
• Otherwise fetch is performed
• Check whether the status is 200. We also check that the type of response is basic, which also indicates that the request is cognate. Requests for third-party resources are not cached in this case.
• The response is added to the cache.

Requests and responses must be cloned because they are streams. The body of the stream can only be consumed once. And as soon as we want to consume them, we want to clone them because browsers have to consume them.

The most common step in activating callbacks is cache management. You want to do this now because you are going to remove the old cache in the installation step, and the old Service Worker will suddenly stop serving the files in the cache.

The following is an example of how you can remove files from a cache that is not whitelisted (in this case, page-1 and Page-2 are in their

self.addEventListener('activate', function(event) { var cacheWhitelist = ['page-1', 'page-2']; event.waitUntil( // Retrieving all the keys from the cache. caches.keys().then(function(cacheNames) { return Promise.all( // Looping through all the cached files. cacheNames.map(function(cacheName) { // If the file in the cache is not in the whitelist // it should be deleted. if (cacheWhitelist.indexOf(cacheName) === -1) { return caches.delete(cacheName); }})); })); });Copy the code

Browser support for Service workers is also getting better:

You can be in the process of this reference all browsers – jakearchibald. Making. IO/isservicewo… .