Service Workers?

Nowadays, developing a web page can involve a ton of technologies, including complex JavaScript logic, multiple dependencies, API fetches, BLOB data, and more. All of these can take a toll on your lovingly built website’s performance. However, there are multiple ways to optimize webpage performance, such as hydration and lazy loading. And that’s where service workers come in to help, with their own caching interface that makes these optimizations a bit easier.

Photo by Ave Calvar on Unsplash

Overview :

Service workers are JavaScript assets that act as a proxy between browsers and servers, offering incredible utility and solving complex problems. They can improve the reliability of your app by providing offline access and boost page performance.

Service workers use a progressive enhancement approach, which means that the process of boosting takes place in a series of steps. On the very first visit to your webpage, they get installed with their baseline functionality. After the initial installation, they work in the background to improve reliability and speed.

Moreover, service workers are an enhancement to existing websites, which means that if a browser that doesn’t support service workers visits the page, the baseline functionality of the webpage won’t break.

example : Think of what happens when you visit a store and download an app.

• A request is made to download the application.
• The app downloads and installs.
• The app is ready to use and can be launched.
• The app updates for new releases.

just like that service gets installed in the very first visit, and progressive improves through its cache interface.

An indispensable aspect of service worker technology is the cache interface, which is a caching mechanism wholly separate from the HTTP cache. This cache interface can be accessed within the service worker scope as well as within the scope of the main thread, and it is programmable through JavaScript, which opens up a ton of possibilities. This means that you can use it based on whatever logic is best for a given website. For example:

• Update outdate or old data in the background with interepting user experience
• Store page markup in the cahce so user can have access offline
• Store static asssets in the cahce and serve them on every subsequent request
• Stream partials content from the network and assemble it with an app shell.

These are some of the examples of caching strategies which make offline experiences possible, and can deliver better performance wihtout any high-latency revalidation checks.

Service worker’s are event driven they depend on call backs and transfering data over the network is inherenttly asynchronous.It takes time to request an asset, for a server to respond and download service workers accommidate this asynchronicity throug han event driven API, using callbacks for events such as:

• When a service worker is installing
• When a service worker is activating
• When a service worker detects a network request.

These Events can registerd using a familiar addEventListener API.

Precaching and runtime caching

The caching interface of service workers has two caching concepts: precaching and runtime caching. Each of these is central to the benefits a service worker can provide.

Precaching is the process of caching assets ahead of time, typically during a service worker’s installation. During this process, key static assets and materials needed for offline access can be downloaded and stored in a cache instance. This can also help improve page speed for subsequent pages that require the precached assets.

Runtime caching, on the other hand, is when a caching strategy is applied to assets as they are requested from the network during runtime. This helps guarantee offline access to pages and assets the user has already visited, making it an app-like experience.

When combined, these approaches to using the cache interface in a service worker provide tremendous benefits to the user experience and can provide app-like behaviors to an ordinary web page.

Service workers are isolated from main thread in a evolving challenge for web, and from a user perspective it depends on the device and its high speed internet its difficult to make high performing website and service workers are user-first design that means they dont take on the main thread to decrease the performace they run in the background, not taking any resource from JS.

Scope and lifecycle :

Photo by Sarah Dorweiler on Unsplash

A service workers scope is based on its location in the directooy if it runs on ‘ /subdir/index.html’ and is located in ‘/subdir/sw.js’ then its scope is ‘/subdir/’ and its subsequent folders.

to see this in action :

• Navigate to https://service-worker-scope-viewer.glitch.me/subdir/index.html. A message will appear that says no service worker is controlling the page. However, that page registers a service worker from https://service-worker-scope-viewer.glitch.me/subdir/sw.js.
• Reload the page. Because the service worker has been registered and is now active, it’s controlling the page. A form containing the service worker’s scope, current state, and its URL will be visible. Note: having to reload the page has nothing to do with scope, but rather the service worker lifecycle, which will be explained later on.

Regardless of scope, a service worker controlling a page can still intercept any network requests, including those for cross-origin assets. Scope limits which pages are controlled by a service worker, not which requests it can intercept.

lifeCycle :

• Register

Registration is the initial step of the service worker lifecycle, When registration begins, the service worker state is set to ‘installing’. Once registration finishes, installation begins.

• Installation

A service worker fires its install event after registration. install is only called once per service worker, and won't fire again until it's updated

• Activation

If registration and installation succeed, the service worker activates, and its state becomes activating Work can be done during activation in the service worker's activate event. A typical task in this event is to prune old caches

• Update

Assuming a service worker’s URL or scope is unchanged, a currently installed service worker only updates to a new version if its contents have changed.

Yet, one exception might be if sessions on a website are long-lived. This can happen in single page applications where navigation request are rare In such situations, a manual update can be triggered on the main thread.

• Installation

One thing to note is that an updated service worker gets installed alongside the previous one. This means the old service worker is still in control of any open pages, and following installation, the new one enters a waiting state until it’s activated.

• Activation

When an updated service worker is installed and the waiting phase ends, it activates, and the old service worker is discarded. A common task to perform in an updated service worker’s activate event is to prune old caches.

And this lifecycle goes on. I hope there was some thing to learn, please share your thoughts and correct me in comment if i am wrong.