4

I was looking at service worker practices and workbox.

There are many articles talking about precaching, workbox even provides special method precachingAndRoute() for just that. I guess I understand the conceptual difference between precache and runtime cache, but what confuses me is why precache is treated so specially?

All articles I've read about precaching emphasize how it makes web app available when client is offline. Isn't that what cache (even it's not precache) is for? I mean it seems that runtime cache can also achieve just that if configured properly. Does it have to be precache to have web app work offline?

The only obvious difference is when the caches are to be created. Well, if client is offline, no cache can be created, no matter it is a precache or runtime cache, and if caches were created during last visit when client was online, how does it matter whether the cache to respond with for current visit was a precache or runtime cache?

Consider 2 abstract cases for compare. Say we have two different service workers, one (/precache/sw.js) only does precache and the other (/runtime/sw.js) only does runtime cache, where /precache and /runtime host same web app (meaning same assets to be cached).

Under what scenario, web app /precache and /runtime could run differently due to different sw setup?

In my understanding,

  • If cache can not be created (e.g. offline on first visit), then precache and runtime cache shouldn't be any different.
  • If precache can be created successfully (i.e. client is online on first visit), runtime cache should too. (Let's not go too wild with cases like the client may be online only for some certain moment, they still should be the same in my examples.)
  • If cache are available, then precache and runtime cache have nothing to do, hence are still the same.

The only scenario I could think of when precache shows advantages, is when cache need to be updated on current visit, where precache makes sure current visit get up to date info. If this is the case, wouldn't a NetworkFirst runtime cache do just about the same? And still, there are nothing to do with "offline", what almost every article I've read about sw precaching would mention.

How online/offline makes precache a hero?

What did I miss here, what's so special about precaching?

Mark Ye
  • 81
  • 4

2 Answers2

3

One scenario where it is different could be the following.

What the app is like:

You have a landing page for your app. You have a handful of routes that can be navigated to

Cache Strat:

If the user goes to the landing page, only the landing page assets would get cached.

Pre-cache Strat:

If the user goes to the landing page, all of the configured pre-cached assets would get cached.

Difference:

So if the user only goes to the landing page, and then later goes offline, the pre-cache strat would allow them to navigate and interact in some way with the other routes of your app, while the cached strat would not allow any navigation to the other routes.

joeycozza
  • 1,284
  • 2
  • 12
  • 15
2

First, your side by side service workers are restricted to those folders or paths. So they are isolated from each other. Second, you should define a caching strategy for your application that has a mixture of preCached assets as well as dynamic plus an invalidation routine/logic.

You want to preCache as much as possible without breaking any dynamic nature of your application. So cache common JS, CSS, images, fonts and pages that are used over and over. Of course have an invalidation strategy in place to keep these up to date. Next handle non-cached network addressable resources (URLs) from the fetch event handler. Cache them as it makes sense. And invalidate cached assets as it makes sense.

For some applications I cache the entire thing. They are usually on the small side, a few dozen to a few hundred pages for example. For a site like Amazon I would never do that LOL. No mater how much is cached I always have an invalidation and update strategy that makes sense for the application/site.

Chris Love
  • 3,740
  • 1
  • 19
  • 16
  • 1
    Thanks for the response. I think the question was misunderstood. It was about why bother doing precaching rather than just runtime caching. It seems precaching only benefits the first visit when the service install fires. Precaching and runtime caching should not do anything differently in following visits. – Mark Ye Oct 04 '20 at 17:33
  • BTW, if interested with removing sw's path restriction, check out this https://www.w3.org/TR/service-workers/#service-worker-allowed – Mark Ye Oct 04 '20 at 22:32
  • I did not misunderstand the question. The reality is it always depends on how the application needs to function. Some assets should be pre-cached, others dynamic. You should also use cache invalidation strategies, etc. Caching is complex and no one size fits all. – Chris Love Oct 09 '20 at 12:34
  • 1
    Yeah, but the question is, what is the difference, and why would you use one over the other, you didn't really answer that. You just gave some generic good advice and said all apps have difference requirements. – joeycozza Jul 06 '21 at 17:37
  • pre-cache items with long invalidation time frames if they are more or less static, or wont change much over time assets/data. dynamically cache with tighter invalidation times/rules for more fluid data. For example if the source data changes every 5 minutes then dynamically cache with a 5 minute invalidation rule. If the source data changes once a week then set the invalidation to a week. – Chris Love Aug 18 '21 at 17:23