Another interesting strategy is network with cache fallback.
Now this seems to make a lot of sense,
we catch a request in a service worker and then we try to reach out to the network and only if that
fetch fails,
only in this case we reach out to the cache and return the asset from the cache,
otherwise if the network access would have been successful, we would have returned the network response
and ignored the cache.
Now this seems to make a lot of sense, doesn't it?
Because here, we take the best from both worlds,
we have assets stored in the cache but we only use it if we have no network access.
Now one downside is that we don't take advantage of the faster response with the cache which is also
good even if we have Internet connection
but the major problem is the way that the network behaves
if a fetch fails, it doesn't happen instantly.
Now this is hard to simulate because here I either can turn my network on or off and if that network is totally
off, the request fails instantly
but imagine a very poor connection where the request times out after maybe 60 seconds, then you would
have to wait for the full 60 seconds until you reach out to the cache as a backup,
that's a horrible user experience of course.
Let me still show you how this would look like because we're going to build up on this and improve it
to find a really good caching strategy
you actually want to use in a lot of cases.
So how would you implement this one?
Back in the service worker file, I'm going to copy our old service worker strategy again and I'm going
to comment it in down here because I want to basically fine tune this a little bit. Now a network
first, then cache strategy would actually look a bit differently.
We wouldn't cache match at the beginning here,
instead what we would do, we would fetch first. We would send event request as a fetch request and then
we would handle any errors.
We don't need to add a then block because if the request is successful, that's great because then we
just use that response and don't care about caching
but if it fails here in this function where we get an error, we could even parse that error and see
why it fails
but in all cases, in there we could then reach out to our cache,
so basically grab that code here and put it in that catch block.
So now we have a look, if we find that request anywhere in our cache
and if we do, then we simply return that response.
Now if we don't do, we don't need to do anything else because reaching out to the network doesn't make sense,
we've been there before,
it didn't work.
So in the end what we can do is we can get rid even rid of this then block, we simply return caches match here
because we only care about what we get back from the cache
and if that is null, so be it,
we tried to go to the network first,
it failed
so now the cache is our best chance if that fails too,
that's how it is.
Let's see how that works like.
So now if I save this, I refresh the page to install the new service worker and then I will open a new
tab and close the old one of course to activate the new service worker and now in there, you will see
this all works fine,
I have internet connection so I can use all of that. In the network tab, you also see that we load everything
from the internet here,
you can tell by the file sizes,
so nothing is coming from the service workers cache here which makes sense because we have a network first
strategy.
Now if I go offline and I reload here, you should see that generally, it still works,
the icons are missing, everything which was in dynamic cache before is missing because we're not doing
dynamic caching here
but in general, it works.
However it works so good here because I turned off the connection, which simply is a signal that there
is no connection.
As I said, I can't simulate a connection which fails after 60 seconds here but if I would have such
a connection here, this would be a super bad solution because there, we would really have to wait for
it to fail before we reach this catch block
and that is a bad user experience.
So using this is not that common,
you might find some cases where you can wait that long, maybe some background fetching you are doing
but in general if it's critical to present something to the user quickly, don't use this strategy, use
it again for assets which you can fetch in the background which don't need to be there immediately where
this might be a nice way of getting them. As a side note, you can of course also connect this with a dynamic
caching strategy, so you return a dynamic by adding a then block to the successful
fetch, here you of course get your response and this is only called if the fetch is successful,
so if we do have Internet connection and that in there, you can basically copy the code from our other strategy
up there,
so you basically just open the cache, the dynamic cache and then you put the request you made and the
response in there and return the response.
So now we're combining this network first strategy with dynamic caching,
still not the best strategy due to the reasons mentioned.
Let's see if that works though,
let's go back to the application and load it, make sure that this is registered and that the service
worker is installed, it is and with it installed, close the tab, open a new one
and there you should see that
now if I go offline, this page here still works with the icons because we have dynamic caching in place,
help won't work.
If I go online again though and navigate around to load both help URLs
and now I go offline again, this works too.
So now again, we got network first with dynamic caching,
still not the best solution due to the timeout problem.