 Hi, my name is Adriana Jara, and today in Unpacking the Workbox, I bring you three patterns to use caching to our advantage and deliver speedy experiences in our PWAs. This episode builds on concepts from past videos, where I talk about pre-caching, runtime caching, caching strategies, and routing. If you are not familiar with those concepts, check them out and come back. I'll leave a link in the description. Before we get to the code, we have to unpack Workbox encapsulation a little bit. So bear with me. Workbox is a set of tools developed to make the implementation of service workers easier. And within Workbox, we have different levels of encapsulation for how to implement a specific task. If we compare managing our image cache with cooking a burger, option one, you cook, make the patties and the buns from scratch. That is the equivalent of implementing the cache with just the service worker API. I'm not going to run through this scenario, but if you want to learn all the basics about service workers, visit this link. Option two, you can buy the buns and patties pre-made and assemble your burger. That is like creating the image cache with the Workbox libraries, which give us flexibility, but the code can still be repetitive. Or you can go to a restaurant and order the burger you want. All you have to do is eat. That would be like using the Workbox recipe. You don't have that much flexibility, but you'll be done with your task with one line of code. Let me show you how to implement options two and three, the caching patterns, not the burger. The first pattern that we check is precisely creating our image cache, typical things we take into account when we implement an image cache. We use a cache-first strategy, which means the service worker serves the asset from the cache if it is there. If not, it will go to the network. We want to perch images that have been cached for a long time, so that we make sure we are getting the updated version the next time it is requested. We probably want to limit the amount of images we cache to be mindful of a storage usage. Here is how all of that looks using Workbox tools. With this line, we tell the service worker to apply this strategy to assets that are images. Here, we indicate the request will be answered using cache first. And using the expiration plugin, we can indicate how many images we want to keep in the cache and how long before we evict them. The next level of encapsulation, we do that with a single line like this. And to this image cache method, you can pass options to modify the number of items to cache, how long to keep them and others. Check out all the options in this link. The next caching recipe allows us to cache Google funds and have them available when needed. There are several reasons to use Google funds, like consistency between different languages or saving resources, because it provides only the required resources for your browser. You can check the project here. This is how the long version of this cache looks like. We configure two separate caches, one for the style sheets, with the font face definitions. Here, we use a stalwart revalidated strategy because these style sheets can change relatively frequently. That will give the server the asset from the cache for a fast load while updating the cache version from the network for the next time it is requested. Then we use a cache first strategy for the font files themselves because they don't change that often. It's okay to save them to our cache and serve them from there for a fast response. Notice that we use some options to configure this cache. A maximum of 60 font files are stored and they are evicted and replaced after one year. These are the values for the default configuration for the one line version of this cache. And here it is, the one line version of all that font talking looks like this. Like with the other recipes, you can pass options to the function. Check out the options available here. Last but not least, the next pattern can help with a metric that is called largest contentful paint. This metric is part of a performance measuring framework called Core Web Vitals. You can check all about that following this link. Check out the code for the long version. From the other patterns, we know more or less what is going on. The idea here is to cache our pages with a network first strategy. And what it does is always go to the network to get the latest version and if the request is successful, saves a copy in our cache. But in this case, we use a timeout time of three seconds. So if maybe because of network conditions, we don't have a response in three seconds, the strategy will fall back and serve the version from the cache, given the user a better experience than waiting forever. And here is the one line version of that with the links to explore the options that we can pass. I know Warbox is big and it has a lot to unpack. You can even combine these recipes if all of them make sense for your app. But I hope this series has given you some ideas of where to start playing with the different tools and how to improve your web app's performance, maybe with a single line of code. Check out all the Warbox documentation in this link. You can subscribe for more Google Developer news and tips. Your comments and questions below are always welcome. Thank you, until next time.