Progressive Web App (PWA) P.2

Service Worker

What is Service Worker?

Service Workers is a JavaScript file that is run by your browser in the background separate from your webpage and handles events fired either by the browser or your webpage. Since it’s run in the background it doesn’t need the webpage to be open and doesn’t show any markup.

How does a Service Worker work?

1. Because a Service Worker runs in the background, they have a different life cycle, which is completely separate from your Web page. And in order to use a Service Worker, it needs to be registered by your app’s JavaScript. If the page has never had a Service Worker before or the Service Worker has been updated.
2. The browsers gets the new service worker and installs it.
3. Once it’s been installed, it’s the activated. The Service Worker will then control all the pages under the scope with one exception. The page that is registered for the Service Worker for the first time, won’t be controlled until it’s loaded again.
4. Once the Service Worker is in control, it will handle fetch, message and push events that occur whenever a network request or message is sent from your page. A browser can terminate a Service Worker to save memory. But it will be restarted as needed.

Note:

• Service Worker require HTTPS. If your site isn’t served over a secure connection, the browser simply won’t load the service worker.
• You should check client’s browser support Service Worker before register it.
• chrome://serviceworker-internals is a super helpful tool.

This is an example from Google.

Register service worker in file service-worker.js

service-worker.js

Introduce about main event in Service Worker.

• When the Service Worker is first registered, it triggers an install event. This is the perfect time to pre-cache all of the resources needed for the App Shell.
• What happens to the files that were previously stored in the cache after installing a new one? So it’s up to you to clean the unused files from the cache. The activate event is the perfect place to do this.
• How do we get it out so that on a slow network or even no network, we’re still able to get the resources required to run our app. For that we’ll to intercept all the network requests by handling the fetch event in the Service Worker.

Strategy

Service Worker are extremely flexible and let you decide how you’re going to cache your assets. There are a handful of caching strategies and choosing the right one depends on your application and what it is you’re caching.

1.Cache first, then network

This is ideal for storing commonly used resources. Such as storing the key components for the app shell. This strategy for application data or resources that change frequently.

2.Network first, then cache

This strategy to use for basic read-through caching. It’s also good to use for API requests where you always want the freshest data when it’s available but would rather have stale data than no data at all. For example article content, social media timelines and game leaderboards.

3.Cache only

This option is good for when you need to guarantee that no network request will be made. For exaple saving battery on mobile devices.

4.Network only

This is ideal for things taht don’t have an offline equivalent for example analytics pings, non-get requests,..

5.Cache and network race

Get fastest response from request the resourece form both the cache and the network in parallel, then it responds with whichever returns first.

6.Cache then network

Like the fastest strategy, two parallel requests are made, one to the cache and one to the network. The idea is to show the cached data first, then update the cache and the page when network data arrives. Take care not to squash the latest data if the network returns before the cache.