62

In my Progressive Web App, should I be using the Cache API in a service worker for my static assets, or should I just rely on the browser's native cache control for these? What's the difference?

Marco Castelluccio
  • 10,152
  • 2
  • 33
  • 48
Joe Marini
  • 1,540
  • 2
  • 11
  • 12

2 Answers2

37

The primary difference is control. Browser cache is driven off Cache-Control headers, which is good, until its not. There are all sorts of strategies to manage how network addressable resources are cached; private, public; time to live, etc.

With service worker caching you can programmatically control how those assets are persisted. But that means the burden is on you.

Browser cache is what I consider unreliable. The browser will automatically purge assets based on device storage availability. For example, iPhones used to ignore caching for any resource over 25kb. Today I think they are just very aggressive.

I know the Facebook team did a study a few years back and found only 25% of the files they expected browsers to cache based on headers were cached. This meant there was extra network traffic and server activity.

This is why service worker caching is the better choice. Don't go removing your cache headers, just don't lean on them.

Chris Love
  • 3,740
  • 1
  • 19
  • 16
  • 9
    I believe this is the study you are talking about for anyone interested: https://code.fb.com/web/web-performance-cache-efficiency-exercise/ – Nooshu Jul 16 '18 at 19:01
  • 2
    Are you sure about that 25% figure? From the link in the comment above looks like is the other way around: "25.5% of all logged requests were missing the cache" meaning that 75% of the files where cached and 25% didn't. – Harry Theo Nov 21 '19 at 14:28
  • 1
    "The browser will automatically purge assets based on device storage availability." SW cache is not immune to this. See: https://developers.google.com/web/ilt/pwa/caching-files-with-service-worker – Joel H Apr 06 '21 at 17:09
36

A major advantage of the service worker cache API is that it gives you more detailed control than the built-in browser cache does. For example, your service worker can cache multiple requests when the user first runs your web app, including assets that they have not yet visited. This will speed up subsequent requests. You can also implement your own cache control logic, ensuring that assets that are considered important are kept in the cache while deleting less-used data.

Joe Marini
  • 1,540
  • 2
  • 11
  • 12
  • 12
    One comment that came up related to this. If using cache headers to cache elements on a page, a user triggered refresh will make the browser skip the HTTP cache. SW fetch event will always intercept a request meaning you can always serve from your cache if you want to. – Matt Gaunt Feb 04 '16 at 23:53
  • 5
    @GauntFace Indeed, and it isn't only on an explicit "refresh" of an open tab. An implicit "refresh," like loading the page in a new tab, will fail if the page was cached with headers and the device is offline. – Myk Melez Feb 17 '16 at 18:33