 Well, hello again. I'm Sarah Clark, and I'm here to help you use Workbox to fulfill all your desires. Well, almost. If those desires include writing a service worker and caching files, you've seen how to use the command line to build a service worker that caches files for offline use. But that's the simplest case. In reality, you may want to pre-cache your app shell, put other pages in a size-limited cache, and put data in a database. Workbox can help you with all of this. Remember when you used the command line to install Workbox and run the wizard? You told the wizard which file extensions to cache and where your files are. It wrote a configuration file you could use to run Workbox. Workbox reads this file and fills in your service worker template. And you ran Workbox from the command line. Before, you registered that service worker and had a working PWA. OK, how are we going to beat that? We're going to introduce you to alternate caching strategies. We'll also look at limiting a cache's size. Here's a typical Workbox configuration file created by the wizard. By default, this pre-caches all of the listed files. And you've seen this code before. It matches all of the images and puts them in their own cache. This means your PWA has two caches, HTML, JavaScript, and CSS together in one cache and images in their own cache. Notice the options block. It lets you set an expiration time, a limit on how many files, or a limit on the total size. Workbox will manage the cache for you, deleting files to stay within the limits. There are quite a few ways to get this wrong, but Workbox's code is well tested and used in Google's production sites. By default, Workbox caches use a cache-only strategy. This caches everything at first launch and always reads from the cache. But this might not be the best strategy for you. Look at the Handler option. It says cache-first, which is one of the built-in strategies. The difference between cache-only and cache-first is that cache-first will fall back to the network when it doesn't have the file. Here's the process. First, the page makes a request that's intercepted by the service worker. Second, the service worker tries the cache. If the resource is found, it's returned to the page. Otherwise, the service worker will try the request on the network and return that. In other words, try the cache-first and fall back to the network. Workbox has five built-in strategies and you can add your own. You've seen cache-only and cache-first. In the same way, there are network-only and network-first strategies. There's also a special strategy called Stale While Revalidate. I'll come back to it in just a minute. Network-first works just like you might expect. When the service worker sees a request, it tries the network-first. If that returns an error or times out, then the service worker uses the cache. Network-only is the same, except it never uses the cache. So how do you know which strategy to use? You need to look at how often files change and whether your app can live without them. First are the files you need to open your app. These include your index.html, main script, and initial CSS files. These probably don't change very often, and you have to reload the app if they do. These are best served with a cache-only strategy, which is the default. They will always serve up quickly, and Workbox will check for changes whenever you open or reload your app. You might remember the technique of loading below the fold images in the background. Your app probably has some content that isn't required immediately, but that you will load later. In this case, use the cache-first strategy. Cache-first tries the cache, then the network if needed. This also places a copy in the cache, so you can start with an empty cache and it will gradually warm up with your most important files. It's a good idea to set a limit on this cache, either the number of entries or its total size. If you have time-sensitive data, such as news or weather, use the network-first strategy. This tries the network, falling back to the cache if the network isn't available. If you do this, hopefully your pages have a timestamp to indicate which are older pieces. Note that you should not do this for real-time data. If you're using real-time data, put up a notice when you're offline or display a summary of the data collected so far. I haven't talked about one very important kind of asset, user avatars. If you have information that changes rarely, but that users really care about, you can use a special technique to keep these up to date. This technique is called stale while revalidate. This technique runs through the service worker as usual. When the service worker sees the request, it checks both the cache and the network at the same time. If the cache comes in first, that's the value used. When the network response comes in and it's different than the cache, then it replaces the old cache entry. In other words, this shows you the old stale data while revalidating to see if there's a newer version. This lets you show a user avatar immediately, but makes sure it's current for next time. And one last reminder, you add each strategy to a different route in your PWA. A route is a URL path, possibly written as a regular expression. See the Workbox documentation for details. Workbox lets you create a service worker without having to write too much code. I've covered its built-in strategies and you can look at their source code in the public Workbox repo. You can even create custom strategies, but that doesn't happen very often. We've been using the command line, but in the next episode, we'll show you how to use Workbox with your favorite build system. See you there.