
### Why Caching ???

Caching helps us speed up application performance .As retrieving files from hard drive will always be faster than getting it from remote server. Moreover we can offen find ourselves in a place with limited network connectivity ,in such cases caching comes in handy for offline access to web applications.

##### Cache API

With web apps there are multiple possible caches to work with.The server can cache resources ,but we cannot use them for offline access. However our browser also have it own cache which we can use when we are not connected to network.The browser cache is however managed by browser.

###### So what do we do now ?

This is where the Cache API joins the party , which provide us access to a seperate cache which also lives in browser but managed by us as a developer.This cache holds key value pairs , where our key is the request (simply put --url) which we send to server and the value is the response we got back.

Thereafter we can cache the response in our cache while we are online and use it when we are offline.

The cache API can be accessed by service workers and javaScript.

Service Worker is a background process which runs even when we have no internet connection , hence we would have no difficulty accessing out cache through it.

By using the fetch event in service worker and the cache API ,we can control if the request is allowed to continue to network or if we want response from cache if it is available in the [CACHE](https://developer.mozilla.org/en-US/docs/Web/API/Cache).

![Service Worker](https://miro.medium.com/max/1122/1*ygpXAWYXCteRJJM1-QmI1Q.png)

##### How do we identify cacheable items?

For starters we look for components that are visible in most pages like header , footer , sidebar and cache them. By doing this we atleast won't see _site can't be reached page_ and then we can think of what we can cache on ondemand basic and lastly we can think of content which changes dynamically.

Let me give an example of where and how we cache things like fonts,icons and 3rd party css.But before that lets discuss about **Service Worker Lifecycle**.

A service worker has a lifecycle that is completely separate from our web page.

To install a service worker for our site, you need to register it, which you do in our page's JavaScript. Registering a service worker will cause the browser to start the service worker install step in the background.

Typically during the install step, we want to cache some static assets. If all the files are cached successfully, then the service worker becomes installed. If any of the files fail to download and cache, then the install step will fail and the service worker won't activate (i.e. won't be installed). If that happens, it'll try again next time. But that means if it does install, we know you've got those static assets in the cache.

When installed, the activation step will follow and this is a great opportunity for handling any management of old caches.

After the activation step, the service worker will control all pages that fall under its scope, though the page that registered the service worker for the first time won't be controlled until it's loaded again. Once a service worker is in control, it will be in one of two states: either the service worker will be terminated to save memory, or it will handle fetch and message events that occur when a network request or message is made from our page.

Below is an overly simplified version of the service worker lifecycle on its first installation.

![Service Worker Lifecycle](https://res.cloudinary.com/scotch/image/upload/v1536590617/kxhshgxmbcl1aw7gncem.png)

```js
var CACHE_NAME = "my-site-cache-v1";
var urlsToCache = ["/", "/styles/main.css", "/script/main.js"];

self.addEventListener("install", function (event) {
  // Perform install steps
  event.waitUntil(
    caches.open(CACHE_NAME).then(function (cache) {
      console.log("Opened cache");
      return cache.addAll(urlsToCache);
    })
  );
});
```

In service worker we work with async code as it is running in background and is events driven.Therefore the install event does not wait for caches.open() to finish by default and mark the installation complete.
Now we have the fetch event listener next and if we try to fetch resource from cache when the caching operation is not finished we can land into trouble.Hence we use event.waitUntil method which waits untill the caches.open() returns a promise that is fulfilled and then mark the installation complete after that.

When the cache is open we can add our resources in the cache using addAll(adds array of items) or add method.

**Cache.add(request)**
Takes a URL, retrieves it and adds the resulting response object to the given cache. This is functionally equivalent to calling fetch(), then using put() to add the results to the cache.

##### Cache and return Requests

Now that we installed a service worker, we probably want to return one of our cached responses, right?

After a service worker is installed and the user navigates to a different page or refreshes, the service worker will begin to receive fetch events, an example of which is below.

```js
self.addEventListener("fetch", function (event) {
  event.respondWith(
    caches.match(event.request).then(function (response) {
      // Cache hit - return response
      if (response) {
        return response;
      }
      // if nothing in cache goto network
      return fetch(event.request);
    })
  );
});
```

**Cache.match(request, options)**
Returns a Promise that resolves to the response associated with the first matching request in the Cache object.

##### Dynamic Caching upon Fetching

Lets say in one of our cached files we have a fetch Event which calls another url (Eg : an image file) .In this case we want to store the response in our cache ,otherwise our app will not work properly offline as response of nested url call is not cached.

```js
self.addEventListener("fetch", function (event) {
  event.respondWith(
    caches.match(event.request).then(function (response) {
      // Cache hit - return response
      if (response) {
        return response;
      }

      return fetch(event.request).then(function (response) {
        // Check if we received a valid response
        if (!response || response.status !== 200 || response.type !== "basic") {
          return response;
        }

        // IMPORTANT: Clone the response. A response is a stream
        // and 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) {
          cache.put(event.request, responseToCache);
        });

        return response;
      });
    })
  );
});
```

###### What we are doing is this??

- Add a callback to .then() on the fetch request.
- Once we get a response, we perform the following checks:
  - Ensure the response is valid.
  - Check the status is 200 on the response.
  - Make sure the response type is basic, which indicates that it's a request from our origin. This means that requests to third party assets aren't cached as well.
- If we pass the checks, we clone the response. The reason for this is that because the response is a Stream, the body can only be consumed once. Since we want to return the response for the browser to use, as well as pass it to the cache to use, we need to clone it so we can send one to the browser and one to the cache.

##### Update a service worker

There will be a point in time where our service worker will need updating.Here we follow following steps

- Update service worker JavaScript file. When the user navigates to site, the browser tries to redownload the script file that defined the service worker in the background. If there is even a byte's difference in the service worker file compared to what it currently has, it considers it new.
- Our new service worker will be started and the install event will be fired.
- At this point the old service worker is still controlling the current pages so the new service worker will enter a waiting state.
- When the currently open pages of your site are closed, the old service worker will be killed and the new service worker will take control.
- Once the new service worker takes control, its activate event will be fired.

One common task that will occur in the activate callback is cache management. The reason we want to do this in the activate callback is because if we were to wipe out any old caches in the install step, any old service worker, which keeps control of all the current pages, will suddenly stop being able to serve files from that cache.

When activate event is triggered we know that user has closed the pages and tabs and opened the application a new one.Now its safe to update cache with new version number and changes and delete the old one.

Let's say we have one cache called 'my-site-cache-v1', and we find that we want to split this out into one cache for pages and one cache for blog posts. This means in the install step we'd create two caches, 'pages-cache-v1' and 'blog-posts-cache-v1' and in the activate step we'd want to delete our older 'my-site-cache-v1'.

The following code would do this by looping through all of the caches in the service worker and deleting any caches that aren't defined in the cache allowlist.

```js
self.addEventListener("activate", function (event) {
  var cacheAllowlist = ["pages-cache-v1", "blog-posts-cache-v1"];

  event.waitUntil(
    caches.keys().then(function (cacheNames) {
      return Promise.all(
        cacheNames.map(function (cacheName) {
          if (cacheAllowlist.indexOf(cacheName) === -1) {
            return caches.delete(cacheName);
          }
        })
      );
    })
  );
});
```

Here also we use waitUntill as if the old cache is not cleaned up we may fetch response from our old cache again instead of new one so we wait for old cache to get deleted.

_References_ :

- [developers.google.com](https://developers.google.com/web)
