7 days of WordPress plugins, themes & templates - for free!* Unlimited asset downloads! Start 7-Day Free Trial

Next lesson playing in 5 seconds

Cancel
  • Overview
  • Transcript

3.1 Caching Basics

PWAs provide an offline experience, and they do so by caching resources. You'll learn how to cache resources in this lesson.

3.1 Caching Basics

In the previous session we created our service worker and it is useless. However, we are going to add some useful functionality. In this lesson we are going to start caching our files. Now, caching is typically thought of as providing an offline experience and yes, we can do that we are going to do that. However, caching is a strategy. We can use caching to enhance the perceived performance of our application. So if we cache things that don't regularly change well, those are things that the client doesn't have to download, except once. So anytime that there's a request for those cached resources, well, it's just gonna pull that from the cache as opposed to downloading from the server. And we can cache anything because really, we don't cache files. We cache responses from the server. So if we make a request for food on HTML, well, that of course doesn't exist. So the response is gonna be a 404. And that would be what is cached if that's what we chose to cache. But we're not. So let's get started. The first thing that we need is a name for our cache because we actually have multiple caches at our disposal. So if we wanted to organize our cashes into different buckets we can do that. But for our purposes, I'm going to just use one cache, we gonna call it static-v1, so this is like the first version of our static cache. And then I'm going to create an array that is going to contain the URLs that we want to cache. Now these URLs are, relative to the URL of our service worker. If you'll remember in the previous lesson I said that it's the easiest place to put our service worker is at the root of our application. That's because when it comes to caching, yeah, so, for example, if we put the ServiceWorker inside of assets js, and we wanted to cache index html, we would have to go back one so that we would be into assets, then back again so that we would be at the root and then index html. That's horrible. So it's just easier to put your ServiceWorker at the root of your application. That way you don't have to do these mental gymnastics to get the correct path. So for right now, we're going to cache two things. We're going to cache the root, and then we're going to cache index HTML. That's kind of redundant in our particular case, but that's okay. We want that, so that if there's a request for just the root of our application that's going to be cached or at least the response is going to be cached. The same is true for index.html. So we've defined what we want to cache now we just need to cache that. And we will do that inside of our install event listener. Now, in the previous lesson, I don't think I explained what self is. This is the global object for our service worker, it's not the window object because we are now within the context of a service worker. So self is kind of the window of the Serviceworker world. And that's why we are using self here. So inside of an event listener event listeners are typically synchronous. And that's going to cause a problem because pretty much all of the API's that we have are asynchronous. So when it comes to working with a cache, what we really want to do is tell our event listener to wait. We don't want the event listener to exit until we are done completely caching all of our resources. So the event object that we get to work with has a method called wait until, and then we pass in a promise that will execute in it will completely execute before our event listener exit's. That's important, especially with caching because remember, we are caching responses. So it's essentially fetching those resources. And if our event listener exits while it's fetching that, then we're not gonna have a cache. So we have this object called caches. And the first thing we want to do is open up our cache. And we're going to use our cache name here. So we could have multiple caches if they have different names. So there you go. So we're going to open up the cache and then we're going to work with that cache by adding URLs to it. And we have a method called addAll where we can pass in an array of URLs and it's gonna cache all of those URLs. And there we go. We now have cached those resources. So we can go to the browser, and we can take a look at our application. And here's the clear storage and you can see that our storage has changed. We now have cache storage, as well as service workers. If we scroll down, we can see that we can look at our cache. We can see that the name is Static-v1. That's the name that we used inside of our ServiceWorker. And then it also has the host that is associated with that name. And if we look at the cache, we can see that we are indeed storing responses. Because we have the name, we have the response, the content type, the content size, and then the time that it was cached. And we can see the results of those responses. And I can't move that up, but we could also look at the headers so that everything is being cashed. So that's really cool. Let's go to our service workers and you're going to notice that our number here has changed. We're on number eight. This is kind of a version number in that it's actually keeping track of the different versions of service workers so as we update, our next update is gonna be number nine, and then so on and so forth. So now that we've cached these resources, we should be able to go offline and access them. So, we can go offline in a couple of different ways. Right here, inside of service workers, we can click on Offline. And that will emulate offline. You can see that there's now this little warning sign next to network. But we can also do the same thing inside of network. Here is a drop down. So it's kind of busy on the screen, but we have the preserve log, we have the disabled cache, and then there's this offline, but this is actually more than that. We can actually throttle or emulate different speeds. We can go offline, we can go online, or we can add our own custom. So from the Application tab whenever we clicked on Offline, it set that to Offline. If we change this back to Online, then we are online. And if we look at the application, the offline's gone. So we want to test what this looks like offline. So let's go offline, let's refresh the page, and we don't see our files. Well, yes, that is by design. Even though we have cached those resources, our service worker doesn't know what to do with them. So we have another event that we can listen for is called a fetch which is aptly named, so that whenever we fetch URL, we can hook into that event. And we can actually take over that event and provide an actual HTTP response that will be displayed in the client and we will look at that in the next lesson.

Back to the top