 Progressive web apps need to be fast and reliable. How can you use caching to avoid network requests, even for a site where you can't possibly cache everything ahead of time? Now, it's easy enough to pre-cache static assets like CSS, JavaScript, and HTML. The core resources you know your users will always need for most routes or pages. But what about dynamic content that you can only cache at runtime? For example, when a customer does a search or views a product on an e-commerce site, you want to be able to cache data, content, and even images and media so that users get a great experience that's progressively enhanced as they use your site. So let's see how to do that. This is an example of an e-commerce site with multiple kinds of data. In this case, there are images and numeric data, as well as HTML and CSS resources, and probably JavaScript. The question here, which data goes where? Well, the general rule is that resources addressed through a URL will be stored in the cache. Dynamic resources will be stored in a client-side data store. For example, AppShell resources, images, and style sheets should be stored in the cache. Dynamic JSON data should be stored in a data store. So here we're using the Cache API and client-side data storage. Well, let's look at storing JSON data locally. Now, the Activate event is a good place to begin. Here we create a products store version one. Inside the products data store, we create a clothing object store. This will hold all of the clothing objects. The clothing object store is identified by ID value. This means that the objects in this store will be organized and accessed by the ID property of the clothing objects. So now let's look at storing resources with the Cache API. A common pattern is to cache assets on service worker installation. Note that event.waituntil ensures that the service worker does not terminate preemptively during async actions. In this example, we create a cache v1 cache and store static assets, that's HTML, CSS, JavaScript, and images, with the cache API. For data, well, we can retrieve that from local storage instead of the network. Here we access products from the data store and retrieve all of the items. These items can then be used to update the UI or whatever is needed. For resources like HTML, CSS, JavaScript, and images, we can retrieve those from the cache instead of the network. Here we add a fetch listener to the service worker. When a fetch is made for a resource, we try to find the resource in the cache and return it. However, if it isn't in the cache, we still want to go to the network for it. So there are plenty of resources to help you get started with all this. For links, take a look at the materials that accompany this video. But first, one more thing. What can we do about actions that a user takes when offline? For example, purchasing a product. Well, we can record those actions in a local data store. It's possible to record actions a user takes while offline. In this example, a user is trying to make an item purchase via HTTP request, which will fail if offline. If the purchase fails, the catch block will execute. And this is where we could store the item or user action locally. So how do we use this once connectivity returns? Well, once connectivity returns, the recorded items or actions can be retrieved and sent to the server. If the requests are successful, the corresponding item or action can be deleted from the local data store. So now you know how to pre-cache static resources, such as HTML, CSS, and JavaScript, and how to deal with data and dynamic content. That helps you to ensure your users get a great experience that's resilient to flaky connectivity and can even work offline. So I hope this has helped you understand the basics of local caching and data storage. Thanks for watching.