 Hi, my name is Ariana Jara. And today, in unpacking the Workbox, we are going to talk about different approaches to caching, and we'll check out a few code snippets to implement them using Workbox. Caches are fundamental to creating a fast, responsive experience for web apps. But caches are a limited resource. We probably can't cache everything in our app. And there are parts of our app that we don't want to cache at all, because we always want to get the latest from the network. So I bring you some tips to help you design your caching strategy wisely. In case you're not familiar with Workbox, it is a set of tools developed to make the implementation of service workers easier. We could develop our caching strategy using nothing but the Service Work API and the Cache Storage API. But it can become repetitive, verbose, and complex. That is what Workbox saves us from. With Workbox, we have tools to tell the service worker which resources we want to cache, when we want to cache them, when we want to update the cache, and more. Here, it is important to make the distinction between pre-caching and runtime caching. To understand the difference, it is necessary to be familiar with the service worker lifecycle. The lifecycle is out of scope for this video, but you can find details following this link. In a nutshell, pre-caching is when we choose a set of resources. And we want those resources to be available from the cache as soon as the service worker takes control on our site so that we can always serve them really fast. There are a number of items that are great candidates for pre-caching. Your web apps start URL, your offline fallback page, and key JavaScript and CSS files. With Workbox, you need a build step for pre-caching. For this, you'll use build tools like Workbox CLI or the Workbox Webpack plugin. To generate a manifest of URLs and revisions, that then will be ingested by the Workbox pre-caching runtime module. Workbox pre-caching will cache the resources atomically at the service worker install event and set up a route to serve the resources using a cache-first strategy. Pre-caching can be complex, but if it fits in our architecture, it is worth our while for the performance benefits. You can check out the complete documentation here. On the other hand, with runtime caching, we add our resources to the cache when they are requested. To serve them faster the next time or have them available when the user is offline or on a slower network connection. I'm making this distinction because there is a third option. You can cache some specific resources before they are requested by the browser, but you don't want them bundled with pre-cache because you want to be able to update those resources without having to release a whole new version of your app to change the pre-cache. For example, your web app can include a page for your best sellers. You want to cache that resource before they are requested for a speed experience, but you don't want to upgrade your app every time those resources change. We call this a warm cache strategy. This is the longer version of how to implement a warm cache strategy on Wordbox. You choose the strategy that you use to serve those assets. With pre-cache, you don't have this flexibility. It is designed to always use a cache-first strategy. You list the resources you want to have available, and you write code in the install event of the service worker to request the assets and add them to the cache. We implemented a shorter version for all that code, and it looks like this. All you need to do is list your URLs and choose a strategy to serve them. By the way, we are talking more about strategies in the next video in the series. So keep an eye out for that one. With a warm cache strategy, you can cache assets before they are requested and also have the flexibility to choose a strategy to serve and update them. Check out Wordbox full documentation for more information on modules and other recipes. You can subscribe for more Google Developer news and tips. Your comments and questions below are welcome. Thank you. Until next time.