A service worker is a script that runs separately in the background.
But, wait. What background? What does it mean by “runs separately” ?
So, no matter how many scripts (or files) you split your code into, it will always run as a single script because it has one execution context.
So when I say it runs separately, it means that it runs concurrently to the main thread, without blocking the main thread or the web page’s UI.
Above image shows a normal network request that goes form client to server and the response comes back from server to the client.
Above image shows, how a network request will go back and forth if there is a service worker registered.
A service worker sits between the client and the server, you can think of it as a proxy. It can intercept every request that goes in and out of the client. So, you can manipulate network request in anyway you want.
Service worker has no access to the DOM API, so it can’t manipulate the DOM directly. However, it can communicate with the page via postMessage interface to manipulate the DOM.
Note: For security reasons, service worker only runs over HTTPS
A service worker goes through 3 steps in its life cycle:
- Register: In this event, a service worker is registered against an origin and a path. The path determines the scope of the service worker that is which part of your web app can a service worker control. The default scope is the location of the service worker file. But let’s say you changed the scope to /myapp/, then the service worker can control requests from like /myapp/ or /myapp/one or /myapp/someendpoint but it cannot control the path higher in hierarchy like https://www.example.com/
- Install: Now, after the service worker is registered, installation of service worker is attempted. Installation only happens if the service worker is new or if there is a difference between the new one and the previously installed one. This installation also fires an “install” event, where you can perform some tasks like pre-cache all the static resources like images, fonts, application shell etc.
- Activate: Now, after the service worker is installed, it starts the activation step. In this step, an activate event is fired. However, an important point to note is that a service will only be activated when there are no pages open that are controlled by the previous service worker. If there is even a single page open that is controlled by previous service worker, this new service worker will enter waiting state. You can also perform some tasks in activate event, for instance you can update the previously cached files.
Now, let’s look at few use cases of the Service Worker -
- You can enhance the performance of your web page, for example storing the resource in the browser cache that the user is likely to need in near future.
- You can make your web app more reliable by showing cached content when user is offline instead of the web app being crashed. This will also build a better user experience. For instance, you can gracefully fallback to a custom offline page.
- You can do heavy computation (that is needed by all the pages) in the service worker script and let all the pages know after it has been completed, so that all the pages can use it.
- And most importantly, service worker is extensively used in the development of Progressive Web Application (PWA).
Using service worker is great way if you want to make your web applications faster and give your users, a better and reliable experience.
If you would like to know more about service worker, go to links mentioned below:
Introduction to Service Worker | Web | Google Developers
We're in the process of restructuring our PWA training resources. You can use the materials linked to from this page…
Service Worker API
Service workers essentially act as proxy servers that sit between web applications, the browser, and the network (when…
Let me know your thoughts in the comments.