 Resource caching can improve performance, increase network resilience and enable offline experiences. That all sounds great, but when should you store resources and how should you update the cache? I'm Sam Dutton and I'm going to show you how to develop caching strategies that make sense for your content and your users. Now there's quite a lot of code in this video, but don't worry, if you get lost you can always refer back to the accompanying labs and workbooks. So the requirement here is to reliably store the right assets at the right time on the client device and to update them when necessary. Now of course you should always make the most of the browser cache whatever you do by setting the correct headers on your server, but the browser cache cannot be accessed or updated programmatically. The cache API on the other hand gives you full control over resource caching. So in this video we'll cover some common caching patterns, in particular how to take advantage of service worker events. So first up the install event. Now this is fired as soon as the service worker code is executed and it's only called once. This is a great time to store stuff like CSS, images, fonts, JavaScript, templates, basically anything you'd consider to be a core static component of the current version of your site. In other words these are things that would make your site entirely non-functional if they failed to fetch. Things in equivalent native app would make part of the initial download package. Now be aware that while this happens any previous version of your service worker is still running and serving pages, so the things you do here mustn't disrupt that. Event wait until takes a promise to define the length and success of the install. If the promise rejects the installation is considered a failure and this service worker will be abandoned. If an older version is running it'll be left intact. Now caches open and caches add all return promises. If any of the resources fail to fetch the cache add all call rejects. By the way we're using the word shell here to refer to core resources used by your app. On install not a dependency is a similar strategy to the previous approach. However it won't delay install completing and won't cause installation to fail if caching fails. This is great for larger resources that aren't needed straight away such as assets for later levels of a game. In the code example here we're not passing the cache add all promise for levels 11 to 20 back to event wait until. So even if it fails the game will still be available offline. Of course you'll have to cater for the possible absence of those levels and you know reattempt caching them if they're missing. So the service worker may be terminated while levels 11 to 20 download if it's finished handling events meaning those levels won't be cached. By the way the background fetch API which is under discussion at the moment will help with cases like this and for larger downloads such as movies. Caching in response to the service worker activate event is ideal for cleanup tasks. Once a new service worker is installed and a previous version isn't being used the new one activates and you get an activate event. Because the old version is out of the way it's a good time to delete unused caches. During activation other events such as fetch are put into a queue so you know a long activation could potentially block page loads. Keep your activation as lean as possible and only use it for things you couldn't do while the old version was active. You might want to enable your users to manually select content they want to make available offline. For example a video or an article or a particular gallery of images. Give the user a read later or save for offline button and when it's clicked fetch what you need from the network and pop it in the cache. The caches API is available from JavaScript in the page as well as from service workers meaning you don't need to involve the service worker to add things to the cache. Updating the cache on every network response makes sense for frequently updated resources such as a users inbox or article contents. If a request doesn't match anything in the cache get it from the network send it to the page and add it to the cache at the same time. This approach is also useful for non-essential content such as avatars but care is needed. If you update the cache in this way for a range of URLs such as avatars you run the risk of bloating storage for your origin. And if the user needs to reclaim disk space you don't want to be the prime candidate. Also make sure you get rid of items in the cache you don't need anymore. To allow for efficient memory usage you can only read a responses body once. In the code example clone is used to create additional copies that can be read separately. The so-called stale while revalidate strategy is ideal for resources which are frequently updated but we're having the very latest version is non-essential. Here's the code for that. If there's a cached version available use it but fetch an update for next time. Now the push API is another feature built on top of service worker. This allows the service worker to be woken up in response to a message from the operating systems messaging service. Push messages can be received even when the user doesn't have a tab open to your site. The service worker is woken up and a push event is fired. Now this can be an ideal moment to cache content relating to a notification such as a chat message or breaking news or even an email. You could also use this for infrequently changing content that benefits from immediate sync such as a to-do list update or a calendar alteration. So the common final outcome of a push event is that a notification is displayed. When tapped this can open a focus a relevant page. The user is online at the time of receiving the push message obviously but they may not be online when they finally interact with the notification. So making this content available offline is really important. So notice that the code here updates caches before showing a notification. The show email notification function in the code sample uses the notification API to display a notification. The notification click listener in the service worker in this example could then display an email. Since the necessary resources were cached in response to the push event the content should display regardless of network conditions. Background sync is another feature built on top of service worker. It allows you to request background data synchronization as a one off or at fixed intervals. This happens even when the user doesn't have a tab open to your site only the service worker is woken up. This is ideal for non urgent updates especially those that happen so frequently that a push message for every update would be too much. For example for social timelines or news stories. As you can see in the code you listen out for the sync event and then in this example synchronize leaderboard data for a game. You can find out lots more about when and how to update the cache and the resources linked to from this video. You might also want to have a look at our resources for learning to use push notifications. So thanks for watching I really hope this was useful.