⚠️ This lesson is retired and might contain outdated information.

Cache External Resources during Runtime with sw-precache

Share this video with your friends

Social Share Links

Send Tweet
Published 7 years ago
Updated 9 months ago

sw-precache allows us to cache all the static assets. But what about external request, like caching fonts coming from a CDN? And images from an external website? In this lesson I’ll show you how you can configure sw-precache in order to cache these external resources applying different strategies.

Instructor: [00:01] So far, we cache all the static assets, including the HTML and JavaScript files, but if I turn off the Internet and reload the page, you'll see that the images are not cached. That's because they are not static. They are retrieved from external resources. We can cache them using runtime caching.

[00:25] Let's put the Internet back and open the Webpack config file. In the sw-precache, we can add a runtime caching key, which is an array of objects. Each object has a URL button key, which is array x for the URLs that we need to cache. Let's check which URLs we need to cache.

[00:53] Open the dev tools, and in there, in a work tab. Let's reload the page and go up to the first one. You see an endpoint from pixon.photos, where I retrieve a json with all the images that later will load. We'll need to cache this one.

[01:17] The images also, they come from the source.unsplash endpoint and the images.unsplash, so we'll need to cache them both, as well. Aside from the images, I'm also using a font from fonts.googleapis. Here is the CSS call, and here the one for the font itself.

[01:40] We can conclude that we want to cache whatever starts with HTTPS// and has one of the Pixon, fonts, source, or images. Aside from the URL button, an object needs also a handler property. Here we have several options. We have the cacheFirst, which will try to load the resource from the cache.

[02:13] If it doesn't exist, it will perform the fetch call to the external resource. The opposite of cacheFirst will be the networkFirst. As you can guess, it will perform the fetch call, and if it fails, it will load it from the cache.

[02:28] We also have another interesting one called fastest. This will perform both the fetch call and will take it from the cache at the same time, in parallel. The interesting part is that even though normally the cached one will be the faster to load, it will perform the fetch call and will be stored in the cache, so the cache is always fresh and updated. Let's keep it with fastest and save the file.

[02:53] Let's run it in production mode. Let's run npm run build and HTTP-server -c -1. Then, let's go and reload the app. If we check the application tab and go to the cache storage, we'll see that not only we have the sw-precache key, but also the $$toolbox-cache entry, which will have the runtime cache with the font, with the list endpoint, and with all the images.

[03:35] Right now, if I turn off the Internet and reload the web page, you'll see that both the font and the images are kept in cache and they are still working. One thing you must keep in mind is that the cache is limited. You can go here to the clear storage and you can see how much you are using and how much you have left. That usually depends on how much space you have left on your hard disk.

[04:06] For this case, we can optimize it by only caching some of the images, but not all of them. Runtime caching allow us to do that by using some options. First, we need to define another runtime caching entry. Let's copy this one we have up here.

[04:25] For the other one, we are going to use it only for the Pixon and the fonts calls, and this one below only for the source and images, which are the two endpoints that give us the images. For the one of the images, let's add an options key with a cache key.

[04:47] Here, we can define a max entries, and let's say five. Max entries will only work if we define also a name for that cache. Let's call it also imageCache. In this way, only five images will be kept in cache. This works with an LRU cache, which stands for list recently used. As you can guess by the name, it's a cache that removes the least used entries and keeps the latest ones.

[05:24] Let's save the file. Let's stop this, run it again, and in here, just to have a fresh install in the clear storage, we can go down here and press the button clear set data. That will also unregister the service worker if you have it checked. Let's reload again.

[05:46] If we go again to the cache storage, we'll see that we have another cache entry, the [inaudible] imagesCache. Here, we'll see only five images cached. Again, this time we go and switch on the Internet. We should see that only some of the images are saved and some others are not. In this way, you can control how many entries you can cache for the runtime caching.

egghead
egghead
~ 31 minutes ago

Member comments are a way for members to communicate, interact, and ask questions about a lesson.

The instructor or someone from the community might respond to your question Here are a few basic guidelines to commenting on egghead.io

Be on-Topic

Comments are for discussing a lesson. If you're having a general issue with the website functionality, please contact us at support@egghead.io.

Avoid meta-discussion

  • This was great!
  • This was horrible!
  • I didn't like this because it didn't match my skill level.
  • +1 It will likely be deleted as spam.

Code Problems?

Should be accompanied by code! Codesandbox or Stackblitz provide a way to share code and discuss it in context

Details and Context

Vague question? Vague answer. Any details and context you can provide will lure more interesting answers!

Markdown supported.
Become a member to join the discussionEnroll Today