Skip to content
This repository has been archived by the owner on Jan 23, 2021. It is now read-only.

Latest commit



39 lines (31 loc) · 2.11 KB

File metadata and controls

39 lines (31 loc) · 2.11 KB

sw-precache? sw-toolbox? What's the difference?

sw-precache ⇒ app shell, sw-toolbox ⇒ dynamic content

It's very common to use sw-precache and sw-toolbox in conjunction with each other, especially when following the App Shell + dynamic content model.

The service worker that sw-precache generates handles the local asset versioning and uses cache-first strategy for your App Shell.

sw-toolbox handles runtime caching strategies for dynamic content, such as API calls, third-party resources, and large or infrequently used local resources that you don't want precached.

Using them together via sw-precache's runtimeCaching

We wanted to make it easier for developers to use the two libraries together. Because sw-precache has to be directly integrated with your build environment and must be responsible for outputting your top-level service worker file, it made the most sense as an integration point to give sw-precache the ability to include the sw-toolbox code and configuration alongside its own configuration. Using the runtimeCaching configuration option in sw-precache is a shortcut that accomplishes what you could do manually by importing sw-toolbox in your service worker and writing your own routing rules. You can confirm this by looking at a sample service-worker.js file generated by sw-precache when the runtimeCaching option is used.

The future

This relationship might change at some point in the future once changes to the service worker specification make it possible to relax the requirement that sw-precache generate the top-level service worker.