Why use a service worker for caching when browser cache handles the caching?

Question

I read that using a service worker for offline caching is similar to browser caching. If so, then why would you prefer a service worker for this caching? Browser caching will check if the file is modified or not and then serve from the cache, and with a service worker we are handling the same thing from our code. By default, the browser has that feature so why prefer a service worker?

Benignity

Answer 1

Service Workers give you complete control over network requests. You can return anything you want for the fetch event, it does not need to be the past or current contents of that particular file.

However, if the HTTP cache handles your needs, you are under no obligation to use Service Workers.

They are also used for things such as push notifications.

Documentation: https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API, https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers

Illative

I second the "complete control over network requests." Service workers can do things like manipulate headers and one resource with another (e.g. if offline) that the browser cache can't do. If all you need is a standard browser cache, there's no reason to re-implement it as a service worker--it's not going to be any faster or easier to use. – Hematite

In agreement with this answer, here are two additional resources that helped me better understand the relationship between the browser's http caching and service workers. "The browser's HTTP cache is your first line of defense, but as you've learned, it's only really effective when loading versioned URLs that you've previously visited" (web.dev/service-workers-cache-storage). "Service workers work best as an enhancement rather than a workaround, so instead of fighting the cache, work with it!" (jakearchibald.com/2016/caching-best-practices). – Pallas

Answer 2

I wanted to share the points that I observed while going through service worker documentation and implemented it.

1. Browser cache is different, as the service worker supports offline cache, the webapp will access the content that is cached, even though the network is not available.
2. Service worker will give native experience.
3. Service worker cannot modify DOM content but still it can serve the pages within its scope. With the help of events like postMessage, the page can be accessed and DOM can be changed.
4. Service worker do not require user interaction or webpage . It runs in the background.

Benignity

"Service worker will give native experience." what do you mean by this? – Fawnia

Native experience by provides Rich offline experiences, periodic background syncs, push notifications – Benignity

Point 1 is possible using browser cache also. It depends how your app has been bundled.... – Nupercaine

Answer 3

Actually, it's slower to response the request when you use sw instead of http cache... Because sw use cache api to store the cache content, it's really slower than the browser cache--memory cache and disk cache.

It's not designed for faster than http cache, howerver, when you use sw, you can Fully customizable the response, I think the Fully customizable is the reason why you should use it.

If your situation is not complicated enough, you should not use it

Danidania