What Is Offline-First?

Traditional web apps used to be entirely dependent on the server. All data, content, design, and application logic were stored on the server. The client was just there to render some HTML to the screen. But as web apps evolved, more and more logic and power was transferred to the client. Web apps started doing data manipulations, template rendering, and more. But unlike native apps, our web apps remained completely dependent on the server. Any disruption in connectivity would cause the app to fail completely.

Offline-first is about accepting a simple truth: offline and low connectivity conditions are inevitable. These conditions should be treated not as a catastrophic failure, but as just another possible state in the life of your web app. A state you should plan for and handle gracefully.

Embracing offline-first means accepting that while some aspects of your app might stop working when the user is offline, many others no longer have to.

Another fundamental aspect of offline-first is handling these changes in connectivity gracefully. Handling a dropped connection gracefully means communicating to the user that some functionality may not be available, or that the data she is looking at may be a few hours old but still exposing as much functionality as possible. Even if you have built a web app that works entirely offline, handling a change in connectivity gracefully might mean reassuring the user that she can still use the app and that her data will not be lost.

Mobile-first means always giving the user the best possible experience for his device.

Offline-first means always giving the user the best possible experience for his current network conditions.

Mix and Match: Creating New Patterns

Now that we have seen a few of the more common caching patterns, let’s examine some ideas of how we can combine them to create new methods for caching and serving content.

Cache on demand

For resources that do not change often and that we do not want to cache during the service worker’s install event, we can extend the cache, falling back to network pattern to save requests that have been returned from the network to the cache.

This effectively creates a system for caching resources on-demand. When a resource is first requested, it won’t be found in the cache. The service worker will retrieve it from the network, store it in the cache, and then return it. The next time this resource is requested again, it will be returned instantaneously from the cache:

self.addEventListener("fetch", function(event) {
  event.respondWith(
    caches.open("cache-name").then(function(cache) {
      return cache.match(event.request).then(function(cachedResponse) {
        return cachedResponse || fetch(event.request).then(
          function(networkResponse) {
          cache.put(event.request, networkResponse.clone());
          return networkResponse;
        });
      })
    })
  );
});

fetch(request).then(function(response) {
  cache.put(request, response.clone());
  return response;
});

Cache, falling back to network with frequent updates

For resources that do change from time to time, but where showing the latest version is less important than returning a fast response (e.g., user avatars), we can modify the cache, falling back to network pattern to always fetch the requested resource from the network even when it is found in the cache. This pattern delivers a fast response from the cache, while fetching a more up-to-date version and caching it in the background. Any changes to the resource fetched from the network will be available the next time the user requests this resource. This combines the benefits of a fast response with a relatively up-to-date response (the content shown is as fresh as it was the last time you requested it):

self.addEventListener("fetch", function(event) {
  event.respondWith(
    caches.open("cache-name").then(function(cache) {
      return cache.match(event.request).then(function(cachedResponse) {
        var fetchPromise =
          fetch(event.request).then(function(networkResponse) {
            cache.put(event.request, networkResponse.clone());
            return networkResponse;
          });
        return cachedResponse || fetchPromise;
      })
    })
  );
});

Our event handler begins with event.respondWith. The rest of our code builds that response.

We begin by opening the cache and trying to find a matching request in it. Whether a match is found or not, the promise returned by cache.match will be resolved and the then callback function will be called. Our callback begins by creating a new fetch request for the requested resource, saving it to the cache, and returning that response. The last line returns to event.respondWith either the cached response or, if that wasn’t found, a promise to return the response from the network.

When we call fetch, it returns a promise and continues executing the script while the fetch is done asynchronously. This allows us to return the cachedResponse in the next line without waiting for the fetch to complete, or return the promise created by fetch (a promise that resolves to the file from the network).

Network, falling back to cache with frequent updates

When it is important to always serve the latest version of a resource available, we can use this twist on the network, falling back to cache pattern. Like the original pattern, this one always attempts to fetch the latest version from the network, falling back to the cached version only if the network request fails. In addition, every time the network is accessed successfully, it updates the cache with the network response:

self.addEventListener("fetch", function(event) {
  event.respondWith(
    caches.open("cache-name").then(function(cache) {
      return fetch(event.request).then(function(networkResponse) {
        cache.put(event.request, networkResponse.clone());
        return networkResponse;
      }).catch(function() {
        return caches.match(event.request);
      });
    })
  );
});

Planning Our Caching Strategy

So far, our approach to handling connectivity issues in the Gotham Imperial Hotel’s app was based solely on the network, falling back to cache pattern. We used this pattern to cache a simplified version of our home page, and when we detected a network error, served that to our users.

This was already a marked improvement over our original app. It is something we can ship and know that it provides added value for our users.

Now that we have learned about the different caching patterns, we can take this further.

It is time to take everything we have learned so far and adopt an offline-first approach for the Gotham Imperial Hotel app. When we are done, the page itself will load instantaneously, while resources in it that change from time to time will load from the network or from the cache if the network is not available.

Let’s examine our home page.

Our home page is composed of a static index.html file that rarely changes between versions. It accesses a number of static images, stylesheets, and JavaScript files. The static files used by index.html can all be cached during installation and are perfect for the cache, falling back to network pattern. This will give us a much faster load time for users who are online, offline, or anywhere in between.

What about the index.html file itself? Since this file rarely changes between versions, we might consider a cache, falling back to network pattern. This approach does come with a significant downside in our case. If this file gets updated, we will have to update our service worker as well to make sure the new file is fetched and cached.

To make matters worse, our users won’t see the new version until the old service worker releases control of the page and a new service worker serving the new file becomes active. You can see how this plays out during each visit in Table 5-1.

This means that even if we update the service worker with a new HTML file, it won’t be shown to the user until his next visit to our app.

Chapter 4 goes into detail of why this is happening and how the service worker moves between these states.

Let’s consider our options for caching index.html:

1. Serve it using the cache, falling back to network pattern. This has the downside of possibly not showing the latest version available, even though it might already be cached. It is, however, a fast and bandwidth-efficient solution.

2. Serve it using the network, falling back to cache pattern. This will always show the latest file available. The downside is that we are passing on the chance to improve the load time of an HTML file that we may already have in the cache.

3. Serve it using the cache, falling back to network with frequent updates pattern. Similar to option 1, this always serves the index.html from the cache, providing us with a very fast response time. In addition, it also checks for an updated index.html file and updates the cache if it exists without requiring us to release a new service worker version. The next time the user loads the page, she will see the latest file. This approach combines a fast response time with an almost always up-to-date file. It does, however, use just as much bandwidth as option 2, or not having a service worker at all.

For the Gotham Imperial Hotel home page, I decided to go with option 3. This approach gives us the benefit of a home page that loads instantly, no matter what the user’s connection is. The main downside to this is that the home page shown may sometimes be an older one until the user refreshes the page (not a big deal in this case, since all dynamic data that may change is cached using patterns that will serve up the most up-to-date data). The second downside is that it fetches the HTML from the network on every visit, even though it may already be in the cache (again, not a big deal as the file is relatively small, and the server can send Expires and ETag headers to make sure it is cached in the HTTP cache).

Looking further down our home page, we see a map created using the Google Maps JavaScript API. This interactive map is loaded from Google’s servers every time our page loads. Since we can’t cache all of Google Maps’ logic and data, we will update our service worker to detect when the Google Maps JavaScript file fails to load and serve an alternate JavaScript file. This file will display a static image with a map instead of a dynamic, interactive map widget. This is progressive enhancement in action. Offline users will see the map as a static image, while online users will get a fully interactive map.

Our home page also loads a JSON file with a list of upcoming events taking place at the hotel. This is data that can change at any time, and we would like for our users to always see the most up-to-date version. We will use the network, falling back to cache with frequent updates pattern to serve this file. This makes sure we always serve the latest data we have access to according to network conditions: live data if the user is online, or the last version we cached if he isn’t.

The events JSON file also includes references to a number of image files, each representing a different event. Since these files are not cached during the installation phase, we can use the cache on demand pattern. Every time one of these files is requested, we will attempt to fetch it from the cache. If it is not found in the cache, we will fetch it from the network, store it in the cache for next time, and return it to the page.

To make sure we never have a broken image on our page, we will also modify our caching code for the event images to show a default fallback image if an image is not found in the cache, and the network is not available. This default image will be cached during the installation phase as an install dependency.

Finally, we will set up a rule to make sure analytics pings are sent directly to the network without any caching or fallback. If the user is offline, these pings should fail.

Let’s summarize our caching strategy for the home page:

1. Return index.html using the cache, falling back to network with frequent updates pattern.

2. Return all static files required to display the home page using the cache, falling back to network pattern.

3. Return the Google Maps JavaScript file from the network. If the request fails, return an alternate script that works offline.

4. Return the events.json file using the network, falling back to cache with frequent updates pattern.

5. Return event image files using the cache on demand pattern, falling back to a default generic image if the network isn’t available and the image isn’t cached.

6. Let analytics pings go through untouched.

Implementing Our Caching Strategy

Before you begin, make sure that your code is in the state we left it in at the end of Chapter 4 by running the following commands in your command line:

git reset --hard
git checkout ch05-start

Now we can get started on implementing our new caching strategy by updating the service worker to cache and serve our full home page, along with all of the static assets required to render it.

Replace the code in serviceworker.js with the following code:

var CACHE_NAME = "gih-cache-v4";
var CACHED_URLS = [
  // Our HTML
  "/index.html",
  // Stylesheets
  "/css/gih.css",
  "https://maxcdn.bootstrapcdn.com/bootstrap/3.3.6/css/bootstrap.min.css",
  "https://fonts.googleapis.com/css?family=Lato:300,600,900",
  // JavaScript
  "https://code.jquery.com/jquery-3.0.0.min.js",
  "/js/app.js",
  // Images
  "/img/logo.png",
  "/img/logo-header.png",
  "/img/event-calendar-link.jpg",
  "/img/switch.png",
  "/img/logo-top-background.png",
  "/img/jumbo-background.jpg",
  "/img/reservation-gih.jpg",
  "/img/about-hotel-spa.jpg",
  "/img/about-hotel-luxury.jpg"
];

self.addEventListener("install", function(event) {
  event.waitUntil(
    caches.open(CACHE_NAME).then(function(cache) {
      return cache.addAll(CACHED_URLS);
    })
  );
});

self.addEventListener("fetch", function(event) {
  event.respondWith(
    fetch(event.request).catch(function() {
      return caches.match(event.request).then(function(response) {
        if (response) {
          return response;
        } else if (event.request.headers.get("accept").includes("text/html")) {
          return caches.match("/index.html");
        }
      });
    })
  );
});

self.addEventListener("activate", function(event) {
  event.waitUntil(
    caches.keys().then(function(cacheNames) {
      return Promise.all(
        cacheNames.map(function(cacheName) {
          if (CACHE_NAME !== cacheName && cacheName.startsWith("gih-cache")) {
            return caches.delete(cacheName);
          }
        })
      );
    })
  );
});

The code is similar to what we had at the end of Chapter 4, except for two changes.

First, we replaced the contents of the CACHED_URLS array to contain index.html instead of sw-index.html, along with all the static files required to display it.

Our second change is in the fetch listener, where we now return index.html instead of sw-index.html from the cache.

These two small changes are enough to give our offline users a home page experience that is almost identical to the online one.

Let’s take it further and improve it so that index.html and all the static files required to display it load instantly, even when the user is online.

Replace the code of the fetch event listener in serviceworker.js with the following:

self.addEventListener("fetch", function(event) {
  var requestURL = new URL(event.request.url);
  if (requestURL.pathname === "/" || requestURL.pathname === "/index.html") {
    event.respondWith(
      caches.open(CACHE_NAME).then(function(cache) {
        return cache.match("/index.html").then(function(cachedResponse) {
          var fetchPromise =
            fetch("/index.html")
            .then(function(networkResponse) {
              cache.put("/index.html", networkResponse.clone());
              return networkResponse;
            });
          return cachedResponse || fetchPromise;
        });
      })
    );
  } else if (
    CACHED_URLS.includes(requestURL.href) ||
    CACHED_URLS.includes(requestURL.pathname)
  ) {
    event.respondWith(
      caches.open(CACHE_NAME).then(function(cache) {
        return cache.match(event.request).then(function(response) {
          return response || fetch(event.request);
        });
      })
    );
  }
});

Our new fetch event handler now behaves differently according to each request’s URL.

The first case we test for is for requests to either the root of our domain or /index.html (both are valid requests for our home page). We handle this request with the cache, falling back to network with frequent updates pattern. The code looks for index.html in the cache, then whether it was found or not the code starts fetching and caching the latest version from the network. It then returns either the cached version immediately, or a promise to return the response from the network if it wasn’t found in the cache.

Because fetch runs asynchronously, the response from the cache can be returned even before the fetch resolves.

This pattern gives us both an instant response (a few milliseconds) from the cache, while guaranteeing a relatively up-to-date HTML file.

The details of this code are explained in the “Common Caching Patterns”.

We end our event handler by testing if the request matches any of the URLs we cached during the service worker’s installation. If so, we respond to the event with a response from the cache. If it is not found in the cache, we attempt to return it from the network (this is the cache, falling back to network pattern).

Requests that match neither of these two conditions will simply pass through our service worker untouched and behave normally.

// These three statements return the same URL
var url_1 = new URL("https://gothamimperial.com/index.html");
var url_2 = new URL("/index.html", "https://gothamimperial.com");
var url_3 = new URL("/index.html", url_1);

// All of the following statements are true
url_1.href     === "https://gothamimperial.com/index.html";
url_1.protocol === "https:";
url_1.hostname === "gothamimperial.com";
url_1.pathname === "/index.html";

We just accomplished the first and second caching goals we set for ourselves in “Planning Our Caching Strategy”. Let’s add a few more conditions to our event handler to take care of individual customizations for different resources.

Replace the code in serviceworker.js with the following code:

var CACHE_NAME = "gih-cache-v5";
var CACHED_URLS = [
  // Our HTML
  "/index.html",
  // Stylesheets
  "/css/gih.css",
  "https://maxcdn.bootstrapcdn.com/bootstrap/3.3.6/css/bootstrap.min.css",
  "https://fonts.googleapis.com/css?family=Lato:300,600,900",
  // JavaScript
  "https://code.jquery.com/jquery-3.0.0.min.js",
  "/js/app.js",
  "/js/offline-map.js",
  // Images
  "/img/logo.png",
  "/img/logo-header.png",
  "/img/event-calendar-link.jpg",
  "/img/switch.png",
  "/img/logo-top-background.png",
  "/img/jumbo-background-sm.jpg",
  "/img/jumbo-background.jpg",
  "/img/reservation-gih.jpg",
  "/img/about-hotel-spa.jpg",
  "/img/about-hotel-luxury.jpg",
  "/img/event-default.jpg",
  "/img/map-offline.jpg",
  // JSON
  "/events.json"
];
var googleMapsAPIJS = "https://maps.googleapis.com/maps/api/js?key="+
  "AIzaSyDm9jndhfbcWByQnrivoaWAEQA8jy3COdE&callback=initMap";

self.addEventListener("install", function(event) {
  event.waitUntil(
    caches.open(CACHE_NAME).then(function(cache) {
      return cache.addAll(CACHED_URLS);
    })
  );
});

self.addEventListener("fetch", function(event) {
  var requestURL = new URL(event.request.url);
  // Handle requests for index.html
  if (requestURL.pathname === "/" || requestURL.pathname === "/index.html") {
    event.respondWith(
      caches.open(CACHE_NAME).then(function(cache) {
        return cache.match("/index.html").then(function(cachedResponse) {
          var fetchPromise = fetch("/index.html")
            .then(function(networkResponse) {
              cache.put("/index.html", networkResponse.clone());
              return networkResponse;
            });
          return cachedResponse || fetchPromise;
        });
      })
    );
  // Handle requests for Google Maps JavaScript API file
  } else if (requestURL.href === googleMapsAPIJS) {
    event.respondWith(
      fetch(
        googleMapsAPIJS+"&"+Date.now(),
        { mode: "no-cors", cache: "no-store" }
      ).catch(function() {
        return caches.match("/js/offline-map.js");
      })
    );
  // Handle requests for events JSON file
  } else if (requestURL.pathname === "/events.json") {
    event.respondWith(
      caches.open(CACHE_NAME).then(function(cache) {
        return fetch(event.request).then(function(networkResponse) {
          cache.put(event.request, networkResponse.clone());
          return networkResponse;
        }).catch(function() {
          return caches.match(event.request);
        });
      })
    );
  // Handle requests for event images.
  } else if (requestURL.pathname.startsWith("/img/event-")) {
    event.respondWith(
      caches.open(CACHE_NAME).then(function(cache) {
        return cache.match(event.request).then(function(cacheResponse) {
          return cacheResponse ||
            fetch(event.request).then(function(networkResponse) {
              cache.put(event.request, networkResponse.clone());
              return networkResponse;
            }).catch(function() {
              return cache.match("/img/event-default.jpg");
            });
        });
      })
    );
  // Handle analytics requests
  } else if (requestURL.host === "www.google-analytics.com") {
    event.respondWith(fetch(event.request));
  // Handle requests for files cached during installation
  } else if (
    CACHED_URLS.includes(requestURL.href) ||
    CACHED_URLS.includes(requestURL.pathname)
  ) {
    event.respondWith(
      caches.open(CACHE_NAME).then(function(cache) {
        return cache.match(event.request).then(function(response) {
          return response || fetch(event.request);
        });
      })
    );
  }
});

self.addEventListener("activate", function(event) {
  event.waitUntil(
    caches.keys().then(function(cacheNames) {
      return Promise.all(
        cacheNames.map(function(cacheName) {
          if (CACHE_NAME !== cacheName && cacheName.startsWith("gih-cache")) {
            return caches.delete(cacheName);
          }
        })
      );
    })
  );
});

The code in this example introduces a few changes.

First, it adds a number of new files to the CACHED_URLS array (including "/js/offline-map.js", "/img/event-default.jpg", "/img/map-offline.jpg", and "/events.json"). Next, it sets a new googleMapsAPIJS variable with the URL of the Google Maps API we need to call (we are setting it once here to avoid repetition later). Finally, it adds a few conditions to the fetch event handler.

The first and last conditions remain unchanged. Between those two, four new conditions have been added. Let’s go over them one by one.

Our first new condition looks for requests for the Google Maps JavaScript API:

if (requestURL.href === googleMapsAPIJS) {
  event.respondWith(
    fetch(
      googleMapsAPIJS+"&"+Date.now(),
      { mode: "no-cors", cache: "no-store" }
    ).catch(function() {
      return caches.match("/js/offline-map.js");
    })
  );
}

If the current request asks for the Maps JavaScript file, we attempt to fetch it from the web. If the user is offline and that request fails, we return an alternate JavaScript file from the cache. This simple JavaScript file (called offline-map.js) contains only a single line of code:

document.getElementById("map-container").classList.add("offline-map");

If the user is offline, this code will run instead of the Google Maps API code and will add a class called offline-map to the map-container div. If you examine our CSS file, you will see that this class sets that div’s background image to a static image containing our map.

Note that we also added both the static map image and this new JavaScript file to our CACHED_URLS array to make sure they are both cached when the service worker installs.

Two final things to note about our offline map code. When fetching the Google Maps JavaScript file, we have to fetch it in no-cors mode; otherwise Google’s server will reject the request (see Appendix C). Second, because Google’s servers return the Maps API JavaScript file with headers that cause the browser to always attempt to return it from the HTTP cache, we have to make sure it is always fetched from the network. Otherwise, our fetch won’t fail, and we would get the Google Maps controls (from the cache), but no map under it (the map data isn’t cached). We accomplish this by fetching with the cache option set to no-store, which skips the cache completely. Unfortunately, at the time of writing, this option is still not supported in all browsers, so we also add a cache-busting timestamp to each request’s query string to make sure each request is unique and will skip the cache. We do this by appending the current time to each request’s URL.

The second new condition in the fetch handler handles requests to the JSON file containing our event data:

if (requestURL.pathname === "/events.json") {
  event.respondWith(
    caches.open(CACHE_NAME).then(function(cache) {
      return fetch(event.request).then(function(networkResponse) {
        cache.put(event.request, networkResponse.clone());
        return networkResponse;
      }).catch(function() {
        return caches.match(event.request);
      });
    })
  );
}

Because this data changes frequently, and we would like to always serve the latest data we have access to, we chose the network, falling back to cache with frequent updates pattern.

We begin by opening our cache (we will need it whether the request to the network succeeds or not). We then try to fetch the request from the network. If the request succeeds, we place the response in the cache and return it. If it does not, we look for a cached response and return that instead.

We continue with a condition that handles requests for event images:

if (requestURL.pathname.startsWith("/img/event-")) {
  event.respondWith(
    caches.open(CACHE_NAME).then(function(cache) {
      return cache.match(event.request).then(function(cacheResponse) {
        return cacheResponse ||
          fetch(event.request).then(function(networkResponse) {
            cache.put(event.request, networkResponse.clone());
            return networkResponse;
          }).catch(function() {
            return cache.match("/img/event-default.jpg");
          });
      });
    })
  );
}

Because these images change frequently, and during development we have no way of knowing which events our clients at the hotel are going to be hosting, we will cache these on demand.

Every time we detect a request for an event image, we begin by opening our cache and trying to find it. We then either return that image if it was found in the cache or attempt to fetch it from the network. If the image was fetched successfully, we place it in the cache for future use and return it.

Figure 5-1. Fallback images shown when images not found in cache

The last condition we added handles requests to Google Analytics, and always responds with content from the network:

if (requestURL.host === "www.google-analytics.com") {
  event.respondWith(fetch(event.request));
}

This code is a bit superfluous. We could have simply removed it and let the browser handle the request using its default behavior (which is the same as what we hardcoded here) to achieve the same result.

In the case of the Gotham Imperial Hotel, this code could have been removed. But in your app, you might run into certain cases where you might want to explicitly define this. For example, your code might have a catch-all that handles all requests, and you would like to handle some exceptions this way.

Application Shell Architecture

In planning our caching strategy so far, we came up with an approach that made sense for content sites. But many progressive web apps you will work on will look a lot less like traditional content sites and more like, well, apps. Let’s turn our attention now to how you might approach caching and serving a more dynamic web app.

The same tools and techniques we have used so far still apply here. We will take all that we have learned and use it to implement a caching strategy that makes sense for web apps—the application shell architecture (also known as app shell).

App shell is not a revolutionary idea. In fact, there is a good chance that you are already structuring your web apps using a similar approach. Many JavaScript frameworks enforce a separation among an app’s content, its user interface, and the logic needed to load, display, and control both. The app shell architecture encourages you to further disconnect the basic logic and resources needed to render your app’s most basic interface from the rest of your app. It encourages you to render as light a shell as possible to the user as soon as possible, populating it with content and additional functionality as it becomes available. It prioritizes the display of structure and content that appears “above the fold” over those that can be put off for later.

App shell’s goal is to present the user with a meaningful experience as soon as possible. A well-designed progressive web app that implements app shell will load and show its basic interface in milliseconds.

Figure 5-2. App shell and full experience compared

When planning your app’s shell, strive to serve the minimal amount of HTML, CSS, JavaScript, and images needed to render the basic user interface. Keep this shell as lean as possible so that it loads and runs as quickly as possible when users visit the app for the first time. It should then be stored immediately in the cache so that on consecutive visits it loads from the cache before a single network call is even made. This will allow your app’s interface to render in milliseconds. Once this initial shell has been displayed to the user, the app can populate it with content and expand it with more functionality.

Don’t forget that one of the core strengths of the web is the ability to deep-link directly to content. Keep in mind when planning your app shell that users may not always start their visit on the home page. The app shell should be relevant whether the user begins her journey on your home page or your user-management page. In Figure 5-2, you can see that the app shell will work whether the users start their journey on the timeline, mentions, or messages page.

By embracing this strategy, you will be able to create apps that load almost instantaneously, presenting a UI to the user as soon as possible, instead of having him stare at an empty page, waiting for the network to respond. You will create an experience that is more like what users have come to expect from native apps than from the web.

Including Content in the Initial Render

There is no rule saying apps using an app shell architecture should only display an empty shell when they first render to the page, then wait for the network before displaying any content. Each case is different, and it may make sense for your app to display cached content as part of the initial render along with the shell—even if that content may be stale.

Before including content in your initial render, ask yourself a few questions first:

1. Will rendering potentially stale content from the cache and then updating it seconds later with fresh content from the network hurt or improve the user experience?

2. Will retrieving and rendering this cached content significantly impact the initial load time and rendering speed of the app?

Important

In the case of our sample messaging app, we may decide that storing old messages in the cache and including them as part of our initial render improves the user experience. Messages that are already cached can be quickly rendered, and the experience of older messages being pushed down by newer ones as they arrive is a part of the app’s normal flow (Figure 5-3).

Chapter 6 looks at how to store data, like these messages, in a local database, and use them to populate an app shell with content.

Figure 5-3. Combining the app shell with cached content in the initial render

As we have already seen, there are no hard rules on what should or shouldn’t go into the app shell (nor is it an architecture that fits all apps). When planning your app’s basic shell, ask yourself what components are absolutely critical to making the first render meaningful? Which components do not rely on any changing data and can always be served from cache? Is there any heavy logic that can be delayed and loaded after the basic interface has rendered? What would a native app developer do?

Achievement Unlocked

Yes, being able to render our app to offline users is awesome. But this chapter has dramatically improved the experience for connected users as well.

Setting aside the obvious improvement for offline users, it is easy to dismiss all that we have achieved in this chapter as a minor win. After all, we are viewing the site through an unrealistically fast connection to a local server.

Let’s gain some perspective.

Using Chrome’s developer tools, we can emulate different connection speeds (see “Developer Tools” for more details), and accurately measure the results.

Let’s see how our home page loads using a 3G connection:

Both with and without a service worker, the home page loads in 13 seconds on the user’s first visit. The amount of bandwidth used is also similar. But once the user visited our site once, the difference on every consecutive visit is astounding:

• The home page loads 4.5 times as fast with the service worker.

• The DOM ready event fires 3.8 times as fast with the service worker.

• The user has to download 91% less data, significantly reducing his costs, and our hosting costs.

Users navigating to the account page from the home page also see tremendous gains:

A gain of 428 ms in the time it takes the DOM to load fully may seem inconsequential. But taken in perspective, it is anything but. When a user clicks the My Account button, having the next screen load in 150 ms versus 578 ms is the difference between the feeling of navigating between web pages and the feeling of navigating between screens in a native app. In Chapter 6 we will improve this page further.

With just a few basic building blocks and a few common caching patterns, we were able to achieve extraordinary results in just a few lines of code. These results improve both the user’s experience and reduce the amount of bandwidth used (saving money for our users and reducing our costs).

Summary

This chapter gave us some great opportunities to look at a few common caching patterns and see how we can use each to solve the different challenges that arise on the road to offline-first bliss.

Hopefully, the different caching patterns outlined in this chapter can help guide you along the way. Just remember that they are not rigid blueprints. Sometimes you will need to mix and match them (e.g., like our event image code that caches on demand, but also implements a generic fallback pattern), and sometimes you will have to come up with something completely different (e.g., if a generic fallback image wasn’t acceptable to our clients, we might have considered parsing the events.json file during the install event and caching the images within it).

There is no preset formula to apply to your web app that will unlock an offline-first badge. When planning the strategy for your app, always consider how and when each resource is needed. Weigh the need for each resource to be up-to-date versus potential performance benefits.

Always consider the user’s behavior and needs first, and use that as a guide to finding the approach that would result in the best user experience.