Exploring Service Workers

Caching Strategies

Kyle Simpson

Kyle Simpson

You Don't Know JS
Exploring Service Workers

Check out a free preview of the full Exploring Service Workers course

The "Caching Strategies" Lesson is part of the full, Exploring Service Workers course featured in this preview video. Here's what you'd learn in this lesson:

Kyle discusses strategies for responding to requests, including loading from the server based on online status, using the cache, caching proactively, and checking the cache before loading from the server.


Transcript from the "Caching Strategies" Lesson

>> Kyle Simpson: To restrict our requests, to make sure we're only gonna deal routing with requests to our own server. We're gonna look at the origin property of these URLs. So we're gonna say if url.origin = location.origin. Location, of course, is the location of our web page. So we're basically saying if these are at the same server, like HTTPS, whatever server, port, or whatever.

If the origins are the same, we're gonna handle the request. And I'm just gonna put down here TODO: figure out CORS requests, okay? Cuz you might wanna make them, and then require that you are loading them from places that have CORS headers. Or you might wanna not, so that you're able to cache them, or you might wanna do them opaquely and then not cache them.

Or you might wanna have fallback strategy, or somewhere in between. All right, so for our purposes then, we wanna start making decisions about the kinds of things that come in. Now, to just start out, there are different strategies that you wanna think about. And as we evolve this, we're gonna have a different strategy for each kind of resource.

But think about what you might want to do with a an outbound request. You might want to first try to load it from the server. And then if it comes back from the server successfully, use that response. That's one strategy, and then you're not using the cache at all.

So there might be some resources that you deliberately say I'm never gonna put them in cache, I always wanna try from the server. You might wanna request it from the server. If it succeeds, you might wanna proactively cache it. So it might not have been one of the ones that cache is a logged out file, like we did before.

But it might be one of those resources that you're requesting that you do want to cache, so that you can provide. You might wanna check the cache first before making the request to the server. So there's some resource requests, which you would prefer to get the cached version of it, and only make a request to the server if you don't.

So here's an example where those strategies differ. You may be wanting to use a service worker, sort of as a way to reduce bandwidth load on your servers. You may be wanting to say we get 40 terabytes of traffic a week from people re-downloading all these resources. And in part, we don't change stuff very often.

But in part, it's because there's so much volatility in browser caches. And we might predict that we could cut that down by 20%, just by having a more aggressive service worker, caching strategy that forces this stuff to stay there until we're really sure that it needs to update.

That's an entirely valid usage for a service worker. If that's the case, if you're trying to avoid that sort of stuff, then you may want the strategy more to be check the cache first, and if it's there, use it. And then allow an updated service worker to clear out caches.

There may be some kinds of resources that you wanna check the cache, and serve it right away. And then also make a request to the server, and then if it comes back, and it's different, then tell the user now it's been updated. So you can see there's a lot of different strategies for how we might wanna handle live requests versus caching.

You may want to try the server only if you're online. Remember, we've now taken care of we know if we're online. You might wanna try the server only if you're online, because if you're offline, trying the server is gonna fail. But if you're offline, you might wanna try the cache.

And if the cache fails, and you're offline, what do you do? Do you give them a 404? That particular question is the reason why I included an offline page. If you open up, if you take a look at the offline.html page that I provided, in our particular case, literally, all it says is it looks like you're offline, and the page you requested couldn't be loaded.

Please try again once you're back online. So I'm trying to provide a friendly notice to the user that they tried to access something, which I didn't have in cache, and I couldn't get from the server. But instead of giving them the browser 404 page, I tried to friendly say, hey, you're offline, and I don't know whether that's available or not.

If you're online, and it's not available, I give you a friendly 404. But if you're offline and it's not available, and it's not in the cache, we need a different thing. We only get 404, we wanna say I don't know if it's available or not, I just can't access it now.

There's a ton of nuance variations to these strategies. And whatever one I've picked here is not necessarily what you wanna do. So I'm really trying to teach you to think like a fisherman, rather than just give you these fish, okay?

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now