In the last lecture, we started adding parts of our app shell to the cache,
now let's make this a bit easier by using addAll. addAll actually takes an array of strings where each
string represents a URL of the request we want to send
and again just as add, the service worker will go ahead make the HTTP request and store the request response
key-value pair in the cache storage, in the given cache we're opening here.
So let's add all the URLs we already have here to that and let's all the other URLs you
want to store,
now there are a couple of those.
Besides these files here, we also have a /src/js/feed.js file which makes sense
storing. We probably also want to store our polyfills,
so let's store js/promise.js and let's store src/js/fetch.js or do we?
What's your take on these two requests being stored?
Think about it for a second and then I'll give you my opinion on that.
Does it make sense to store these polyfills in our cache?
In my opinion, it doesn't because we use these polyfills for older browsers.
Now these browsers won't support service workers anyways, so there's no value in storing these files
in the cache.
If we store them there, we only load them for browsers which don't need them,
so we can also remove them from there,
it doesn't hurt if we don't have them cached.
Now from a performance perspective, storing them in the cache might still be worth it because even modern
browsers have to load these files because we simply import them in the HTML file.
Now that is something you can optimize in your build workflow if you have one, to only include or to
conditionally load these polyfills only on browsers where you need it.
Now here, I will add them to the cache for the performance reason so that we can quickly load them
but I want to give you or I want you to keep that in mind, that these are only needed on browsers which
don't support service workers
but since we have to load the files on all browsers, caching them might still make sense, only because
we don't have a build workflow where we would conditionally load this though.
If you have such a workflow or have any other set up, this might not make sense, here
it does however.
So with that, we loaded these Javascript files, there's one other file we should store, source Javascript
and that's the material.min.js file, a file required by that package I'm using, the material
design lite package.
So these are Javascript files,
what about CSS?
Let's have a look at these files too.
There I'll store src/css/app.css and src/css/feed.css,
what about help.css and the index.html
file in the help page?
We could pre-cache that but I want to store the bare minimum app shell we have
and also parts we need to make our front our first page run, like the feed.js file.
This is why I don't pre-cache the files from the other parts of the app,
however you'll soon learn how to dynamically add files to the cache once the user visited a given page,
so that you can provide them on future visits too,
for now I won't pre-cache them though.
So these are the Javascript, HTML and CSS files
but we also got some files which are loaded over the wire and we get images. Now in our index.html
file,
right now we only use one of these images, except for the one which we load dynamically which isn't important
here because this won't work anyways,
we don't have internet connection to do so.
The image we're using however is this main-image.jpg
file, so pre-caching that makes sense too.
We don't have to but for the best user experience, we should probably add this too,
so let's add /src/images/main-image.jpg.
Now what about the icons here?
Well the icons, you don't really need to pre-cache those in my opinion because yes, you won't be able to add
it to the homescreen if you don't pre-cache
the icons here because the browser can't fetch it
but that shouldn't be an issue here because offline support shouldn't be the permanent state of our
application.
Feel free of course to cache some of the icons if you need them in your application,
I will decide against it and stick to the core assets of my main page and not focus on any other assets
in this application.
Other things I want to pre-cache though are the things I get from CDNs, like the styling package here
from material-design-lite or the Google fonts and image
icon sets. So to pre-cache those,
I'll just copy that link here to the roboto font and I will add it to my cache. Here
however I need the full URL, not just /css and so on
because of course it's not loaded from my localhost, not from my domain here but from a different server
but and this is important,
you can also cache files loaded from other service over a CDN, this is perfectly fine,
doesn't have to be your own server. So this is one thing I will pre-cache here.
One important restriction though,
if you don't want to get an error here, the servers you are pre-caching from should set the CORS headers
to allow cross-origin-access to these files,
if they don't, this will throw an error.
So storing the font here is only one thing,
I also want to store the icons,
so let's add this URL to the cache too
and finally let's also add the link to that CSS file we are using, to our theme,
let's add that too. And with that, I think we're pre-caching everything we need, so we can remove these two caching
lines down there and now see if that works as it should.
Let's go back to our application and reload to fetch the new version of the service worker, activate it
and reload the page
and now click on network
and let's see where the files are getting loaded from.
A lot of stuff is coming from the service worker
and we don't see that many requests coming from the network thereafter, the get request and this cryptic
request.
Now this cryptic requests are our actual fonts,
let me show you what I mean.
If we tick offline and we reload, you
see a lot
works here, looks pretty good,
we have the general styling of the image.
We have the font here but the icon is missing, right,
we have some text here.
The reason for this is that the icons here are fetched differently.
We're pre-caching this link but if we carefully evaluate this link here in our network tab, it's this
one and we have a look at the response,
we see that we get back some font definitions where in the end the fonts are loaded from a different
URL, here it's this cryptic URL with 2fcr.
Well if you have a look at the requests, this is this request which is then again sent over the wire.
So we are pre-caching the font definition,
this works, we're fetching this from cache but the actual icons still are fetched over the wire unfortunately.
So this doesn't work yet,
we'll fix this with dynamic caching in the future,
what does work though is, even though it's not super beautiful because the icons are missing,
the application is generally working,
even the Javascript otherwise we couldn't open that menu here.
So this is working,
we can open our own menu, just the icons are missing and if we navigate to help of course, the app breaks
because we're not caching that.
Now it would be nice if we could cache pages or if we could dynamically add assets to the page,
for example if the user visits this page, maybe we want to cache the things we need to display this cache
thereafter, so that future visits are also possible offline.
The same for these icons which still have to be fetched from the wire.
Maybe it would be nice if we could catch that response and dynamically add it to the cache so that we
have it available for future requests too. Dynamic
caching is what I'll have a look at next.