Service worker

Tram Ho

Hi everyone, today we will learn about the Service worker concept

Service worker

Service worker is a script that is run in the background by the browser (browser) and is separate from the website that installs it

Service worker provide features that do not require interaction with the web page or the user such as:

  • Handling network requests ( cache responses )
  • Handling push notification
  • Background sync

Service worker can not access directly into the DOM , instead, the service worker to communicate with those pages are managed by response of the message sent by postMessage , from which the pages will modify DOM on demand

Currently, most browsers now support Service workers (except IE)

Service worker life cycle

The service worker lifecycle is separate from the web page

To install service worker for a website, first need to register it, the register is done in the javascript section of the website. After successful register , the browser will proceed to run the install service worker step implicitly

Once the install successful, it will activate , after successfully activated , the service worker will manage all the pages in the regiter scope . Now the service worker will process the fetch or message event that occurs when there is an network request or message sent from the web page

Register service worker

In the register step, we need to check whether the browser supports service worker or not (in the navigator variable), then register with the serviceWorker object in the navigator , the passed parameter is the path to the script service worker file.

The register function will check if the service worker has been register or not, if not, then proceed to register , return a promise containing the variable registation (an object of ServiceWorkerRegistration )

service worker scope depends on the location it is register , in the above example it is /service_worker_page.js , meaning it is register at the root of the domain , now the service worker can receive all fetch events in the entire domain . If the service worker is register in a different location (eg /admin/sw.js ) then the service worker can only receive fetch events in pages with urls starting with /admin/index , /admin/users , …

Install + Activate service worker

As mentioned above, after the register successful, the browser will proceed to run the install service worker step in the background in the register script , and the activate step is executed right after:

Here self is an object of ServiceWorkerGlobalScope :

After successfully activate service worker , you can check the active status of the service worker :

We will take a closer look through service worker caching :

Cache response

One of the feature of service worker is to handle network requests are sent, cache response and reuse as needed (speed up page load, display cached data to users when network connection is lost ( progessive web app ))

At the install service worker step, the necessary response(html, js, css) will be cache (in CacheStorage ):

cacheUrls contains request to the server want to be cache , the response returned from the server will be cache in CacheStorage :

Then the network request sent ( html, js, css, ... ) will trigger the fetch event and be handle by the service worker :

For the request (stored in e.request ) that the cache response will be returned directly to the browser , new request will be fetch new to the server (we can also cache these new request again)

Even if the network connection is lost, the browser can still show the user previously cache data :

Just recently, I learned about Service worker , thank you everyone for watching

Share the news now

Source : Viblo