 One of the main features of progressive web apps is their ability to work even when offline. We're going to walk through an example of converting a static site for offline use, then you get to do it yourself. But let's take a step back and ask, why do this? As Sam mentioned at the start, most of the growth in internet traffic comes from mobile first and, in some cases, mobile-only connections. This is often in regions where internet connectivity is sparse, expensive, or just unreliable. If you can cache the files appropriately, users can still have something under any conditions. It's also much faster to get files from the cache, giving your page native-like performance. So how can we make an existing site work offline? You could depend on the browser cache, but it fails if the browser is offline. You might use the older app cache, but it has trouble with file updates and redirections. The service worker was designed to address these problems. You need to write a script that does two things. Fetch is in stores static assets via the cache API and then intercepts fetch events inside the service worker and retrieves the file from the cache. But first, you need to enable the service worker. It's exposed on window.navigator, and the best test is to use the in keyword to check for the property. Call serviceworker.register and pass in the name of the service worker's script. This returns a promise that resolves when the service worker is ready or rejects it if it fails. We won't use the contents of the registration here, but you normally want to save it to support features like push notifications. Let's turn our attention to the script inside the service worker. We'll start by downloading and storing the site's files in the cache. The top of serviceworker.js defines a cache name and a list of paths to cache. Notice this. We're caching. That's the path of the current directory. We're also caching index.html. Since you can get to the home page either way, you need to cache both paths. We're also caching the site's CSS file. Notice you can list the file path or even a complete URL and the cache API will find it. We're going to add those files to the cache, but first we need a bit of boilerplate code. The service worker will emit an install event after registration. The keyword self refers to the service worker when called inside a service worker script and window when called outside. So we listen for the install event on self to start building the cache. Remember that the service worker can quit when it's not busy. Calling event.wait until keeps it alive while we build the cache. Call caches.open to create a new named cache. It returns a promise. Then call add all on the cached automatically fetch and add the files. Note that you may want to catch and log any errors in case there's a problem with your file list. Now that we have the files in the cache, we need the code to retrieve them. We're going to do this by listening for the fetch event. Here's our fetch handler. Again, we're installing the listener on self. The browser calls this for each file under the service worker's control. We get the request and look for it in the cache. If the file is found, response will be a fetch response object. In this case, the logical OR operator, written as two vertical bars, evaluates the value on the left-hand side and returns it if it's not null. Otherwise, if it is null, we call fetch to get the file from the network. In other words, we try the cache first and if it fails, we fall back to the network. Calling event.respondwith returns the result. Now it's your turn. Go to the offline quick start lab. In there, we'll recreate the code we looked at here. When you're done, you'll have a site that works offline in browsers that support service worker. If you're an instructor, this final slide links to more information on fetch. If you're a student, these links can be found in your textbook. You may want to use these while you're working on the lab. And there's one last thing, a few more steps to make your app more polished. You may want to pause the video now and do the lab. If not, let's forge on. In this extra credit section, we'll touch on a couple of things to make your app even better. The first technique is making your app installable on mobile devices. You can add a manifest file named manifest.json in the root directory of your app. This lets you specify an icon for the home screen, a name for the application, and even customize the color of the browser chrome. Note that at the time of this recording, this only works on blink-based browsers such as Chrome and Opera. Mozilla and Apple offer similar options using an install file or meta tags. See their documentation for details. The textbook will have the latest techniques. Now let's improve how we handle the cache. In our original example shown here, we cached a few files and retrieved the rest from the network. Can we do better? Let's cache any files that we discover are missing from the cache. In this example, we've replaced the fetch operation with a custom fetch and cache function. Here's the function. We fetch the file, open the cache, store the file, and return the response. Notice the call to response.clone. Each response object can be consumed only once, so we make a copy to store in the cache. And that's it. You've now seen the heart of an offline-enabled app. We'll go into more sophisticated techniques later, but you could use this approach today to offline enable your sites and simple apps. Finish the lab if you need to, experiment on your own code, and come back for the next lesson. I'll see you soon.