Repository files navigation

sw-toolbox andsw-precache are deprecated in favor of Workbox.Please readthis migration guidefor information on upgrading.

Service Worker Precache is a module for generating a service worker thatprecaches resources. It integrates with your build process. Once configured, itdetects all your static resources (HTML, JavaScript, CSS, images, etc.) andgenerates a hash of each file's contents. Information about each file's URL andversioned hash are stored in the generated service worker file, along with logicto serve those files cache-first, and automatically keep those files up to datewhen changes are detected in subsequent builds.

Serving your local static resources cache-first means that you can get all thecrucial scaffolding for your web app—your App Shell—on the screen without havingto wait for any network responses.

The module can be used in JavaScript-based build scripts,like those written withgulp, and it also provides acommand-line interface. You can use the moduledirectly, or if you'd prefer, use one of thewrappersaroundsw-precache for specific build environments, likewebpack.

It can beused alongside thesw-toolboxlibrary, which works well when following the App Shell + dynamic content model.

The full documentation is in this README, and thegetting started guide provides a quicker jumping off point.

To learn more about the internals of the generated service worker, you can readthis deep-divebyHuang Xuan.

• Install
• Usage
  • Overview
  • Example
  • Considerations
  • Command-line interface
• Runtime Caching
• API
  • Methods
    • generate(options, callback)
    • write(filePath, options, callback)
  • Options Parameter
    • cacheId [String]
    • clientsClaim [Boolean]
    • directoryIndex [String]
    • dontCacheBustUrlsMatching [Regex]
    • dynamicUrlToDependencies [Object⟨String,Buffer,Array⟨String⟩⟩]
    • handleFetch [boolean]
    • ignoreUrlParametersMatching [Array⟨Regex⟩]
    • importScripts [Array⟨String⟩]
    • logger [function]
    • maximumFileSizeToCacheInBytes [Number]
    • navigateFallback [String]
    • navigateFallbackWhitelist [Array⟨RegExp⟩]
    • replacePrefix [String]
    • runtimeCaching [Array⟨Object⟩]
    • skipWaiting [Boolean]
    • staticFileGlobs [Array⟨String⟩]
    • stripPrefix [String]
    • stripPrefixMulti [Object]
    • templateFilePath [String]
    • verbose [boolean]
• Wrappers and Starter Kits
  • CLIs
  • Starter Kits
  • Recipes for writing a custom wrapper
• Acknowledgements
• Support
• License

Local build integration:

$ npm install --save-dev sw-precache

Global command-line interface:

$ npm install --global sw-precache

1. Make sure your site is served using HTTPS!Service worker functionality is only available on pages that are accessed via HTTPS.(http://localhost will also work, to facilitate testing.) The rationale for this restriction isoutlined in the"Prefer Secure Origins For Powerful New Features" document.

2. Incorporatesw-precache into yournode-based build script. It shouldwork well with eithergulp orGrunt, or other build scripts that run onnode. In fact, we've provided examples of both in thedemo/ directory. Eachbuild script indemo has a function calledwriteServiceWorkerFile() thatshows how to use the API. Both scripts generate fully-functional JavaScript codethat takes care of precaching and fetching all the resources your site needs tofunction offline. There is also acommand-line interfaceavailable, for those using alternate build setups.

3. Register the service worker JavaScript. The JavaScript that's generatedneeds to be registered as the controlling service worker for your pages. Thistechnically only needs to be done from within a top-level "entry" page for yoursite, since the registration includes ascopewhich will apply to all pages underneath your top-level page.service-worker-registration.js is a samplescript that illustrates the best practices for registering the generated serviceworker and handling the variouslifecycle events.

The project'ssamplegulpfile.js illustrates the full use of sw-precachein context. (Note that the sample gulpfile.js is the one in thedemo folder,not the one in the root of the project.) You can run the sample by cloning thisrepo, usingnpm install to pull in thedependencies, changing to thedemo/ directory, running`npm bin`/gulp serve-dist, andthen visitinghttp://localhost:3000.

There's also asampleGruntfile.js that shows service worker generation inGrunt. Though, it doesn't run a server on localhost.

Here's a simpler gulp example for a basic use case. It assumes your site's resources are located underapp and that you'd like to cacheall your JavaScript, HTML, CSS, and image files.

gulp.task('generate-service-worker',function(callback){varswPrecache=require('sw-precache');varrootDir='app';swPrecache.write(`${rootDir}/service-worker.js`,{staticFileGlobs:[rootDir+'/**/*.{js,html,css,png,jpg,gif,svg,eot,ttf,woff}'],stripPrefix:rootDir},callback);});

This task will createapp/service-worker.js, which your client pages need toregister before it can take control of your site'spages.service-worker-registration.js is a ready-to-use script to handle registration.

• Service worker caching should be considered a progressive enhancement. If you follow the model ofconditionally registering a service worker only if it's supported (determined byif('serviceWorker' in navigator)), you'll get offline support on browsers with service workers andon browsers that don't support service workers, the offline-specific code will never be called.There's no overhead/breakage for older browsers if you addsw-precache to your build.

• All resources that are precached will be fetched by a service worker running in a separatethread as soon as the service worker is installed. You should be judicious in what you list in thedynamicUrlToDependencies andstaticFileGlobs options, since listing files that are non-essential(large images that are not shown on every page, for instance) will result in browsers downloadingmore data than is strictly necessary.

• Precaching doesn't make sense for all types of resources (see the previouspoint). Other caching strategies, like those outlined in theOffline Cookbook, can be used inconjunction withsw-precache to provide the best experience for your users. Ifyou do implement additional caching logic, put the code in a separate JavaScriptfile and include it using theimportScripts() method.

• sw-precache uses acache-first strategy, which results in a copy ofany cached content being returned without consulting the network. A usefulpattern to adopt with this strategy is to display a toast/alert to your userswhen there's new content available, and give them an opportunity to reload thepage to pick up that new content (which the service worker will have added tothe cache, and will be available at the next page load). The sampleservice-worker-registration.js fileillustratesthe service worker lifecycle event you can listen for to trigger this message.

For those who would prefer not to usesw-precache as part of agulp orGrunt build, there's acommand-line interface which supports theoptions listed in the API, provided via flags or anexternal JavaScript configuration file.

Hypenated flags are converted to camelCaseoptions.
Options starting with--no prefix negate the boolean value. For example,--no-clients-claim sets the value ofclientsClaim tofalse.

Warning: When usingsw-precache "by hand", outside of an automated build process, it's yourresponsibility to re-run the command each time there's a change to any local resources! Ifsw-precacheis not run again, the previously cached local resources will be reused indefinitely.

Sensible defaults are assumed for options that are not provided. For example, if you are insidethe top-level directory that contains your site's contents, and you'd like to generate aservice-worker.js file that will automatically precache all of the local files, you can simply run

$ sw-precache

Alternatively, if you'd like to only precache.html files that live withindist/, which is asubdirectory of the current directory, you could run

$ sw-precache --root=dist --static-file-globs='dist/**/*.html'

Note: Be sure to use quotes around parameter values that have special meaningsto your shell (such as the* characters in the sample command line above,for example).

Finally, there's support for passing complex configurations using--config <file>.Any of the options from the file can be overridden via a command-line flag.We strongly recommend passing it an external JavaScript file defining config viamodule.exports.For example, assume there's apath/to/sw-precache-config.js file that contains:

module.exports={staticFileGlobs:['app/css/**.css','app/**.html','app/images/**.*','app/js/**.js'],stripPrefix:'app/',runtimeCaching:[{urlPattern:/this\\.is\\.a\\.regex/,handler:'networkFirst'}]};

That file could be passed to the command-line interface, while also setting theverbose option, via

$ sw-precache --config=path/to/sw-precache-config.js --verbose

This provides the most flexibility, such as providing a regular expression fortheruntimeCaching.urlPattern option.

We also support passing in a JSON file for--config, though this providesless flexibility:

{"staticFileGlobs": ["app/css/**.css","app/**.html","app/images/**.*","app/js/**.js"  ],"stripPrefix":"app/","runtimeCaching": [{"urlPattern":"/express/style/path/(.*)","handler":"networkFirst"  }]}

It's often desireable, even necessary to use precaching and runtime caching together. You may have seen oursw-toolbox tool, which handles runtime caching, and wondered how to use them together. Fortunately,sw-precache handles this for you.

Thesw-precache module has the ability to include thesw-toolbox code and configuration alongside its own configuration. Using theruntimeCaching configuration option insw-precache (see below) is a shortcut that accomplishes what you could do manually by importingsw-toolbox in your service worker and writing your own routing rules.

Thesw-precache module exposes two methods:generate andwrite.

generate takes inoptions, generates a service workerfrom them and passes the result to a callback function, which musthave the following interface:

callback(error, serviceWorkerString)

In the 1.x releases ofsw-precache, this was the default and only methodexposed by the module.

Since 2.2.0,generate() also returns aPromise.

write takes inoptions, generates a service worker from them,and writes the service worker to a specified file. This method alwaysinvokescallback(error). If no error was found, theerror parameter willbenull

Since 2.2.0,write() also returns aPromise.

Both thegenerate() andwrite() methods take the same options.

A string used to distinguish the caches created by different web applications that are served offof the same origin and path. While serving completely different sites from the same URL is notlikely to be an issue in a production environment, it avoids cache-conflicts when testing variousprojects all served off ofhttp://localhost. You may want to set it to, e.g., thenameproperty from yourpackage.json.

Default:''

Controls whether or not the generated service worker will callclients.claim()inside theactivate handler.

Callingclients.claim() allows a newly registered service worker to takecontrol of a page immediately, instead of having to wait until the next pagenavigation.

Default:true

Sets a default filename to return for URL's formatted like directory paths (inother words, those ending in'/').sw-precache will take that translationinto account and serve the contents a relativedirectoryIndex file whenthere's no other match for a URL ending in'/'. To turn off this behavior,setdirectoryIndex tofalse ornull. To override this behavior for oneor more URLs, use thedynamicUrlToDependencies option to explicitly set upmappings between a directory URL and a corresponding file.

Default:'index.html'

It's very important that the requestssw-precache makes to populate your cacheresult in the most up-to-date version of a resource at a given URL. Requeststhat are fulfilled with out-of-date responses (like those found in yourbrowser's HTTP cache) can end up being read from the service worker's cacheindefinitely. Jake Archibald'sblog postprovides more context about this problem.

In the interest of avoiding that scenario,sw-precache will, by default,append a cache-busting parameter to the end of each URL it requests whenpopulating or updating its cache. Developers who are explicitly doing "the rightthing" when it comes to setting HTTP caching headers on their responses mightwant to opt out of this cache-busting. For example, if all of your staticresources already include versioning information in their URLs (via a tool likegulp-rev), and are served withlong-lived HTTP caching headers, then the extra cache-busting URL parameteris not needed, and can be safely excluded.

dontCacheBustUrlsMatching gives you a way of opting-in to skipping the cachebusting behavior for a subset of your URLs (or all of them, if a catch-all valuelike/./ is used).If set, then thepathnameof each URL that's prefetched will be matched against this value.If there's a match, then the URL will be prefetched as-is, without an additionalcache-busting URL parameter appended.

Note: Prior tosw-precache v5.0.0,dontCacheBustUrlsMatching matched againstthe entire request URL. As of v5.0.0, it only matches against the URL'spathname.

Default: not set

Maps a dynamic URL string to an array of all the files that URL's contentsdepend on. E.g., if the contents of/pages/home are generated server-side viathe templateslayout.jade andhome.jade, then specify'/pages/home': ['layout.jade', 'home.jade']. The MD5 hash is used to determine whether/pages/home has changed will depend on the hashes of bothlayout.jade andhome.jade.

An alternative value for the mapping is supported as well. You can specifya string or a Buffer instance rather than an array of file names. If you use this option, then thehash of the string/Buffer will be used to determine whether the URL used as a key has changed.For example,'/pages/dynamic': dynamicStringValue could be used if the contents of/pages/dynamic changes whenever the string stored indynamicStringValue changes.

Default:{}

Determines whether thefetch event handler is included in the generatedservice worker code. It is useful to set this tofalse in development builds,to ensure that features like live reload still work. Otherwise, the contentwould always be served from the service worker cache.

Default:true

sw-precache finds matching cache entries by doing a comparison with the full request URL. It'scommon for sites to support URL query parameters that don't affect the site's content and shouldbe effectively ignored for the purposes of cache matching. One example is theutm_-prefixed parameters used for trackingcampaign performance. By default,sw-precache will ignorekey=value whenkey matchesany ofthe regular expressions provided in this option.To ignore all parameters, use[/./]. To take all parameters into account when matching, use[].

Default:[/^utm_/]

Writes calls toimportScripts()to the resulting service worker to import the specified scripts.

Default:[]

Specifies a callback function for logging which resources are being precached anda precache size. Usefunction() {} if you'd prefer that nothing is logged.Within agulp script, it's recommended that you usegulp-util and pass ingutil.log.

Default:console.log

Sets the maximum allowed size for a file in the precache list.

Default:2097152 (2 megabytes)

Sets an HTML document to use as a fallback for URLs not found in thesw-precache cache. Thisfallback URL needs to be cached viastaticFileGlobs ordynamicUrlToDependencies otherwise itwon't work.

// via staticFileGlobsstaticFileGlobs:['/shell.html']navigateFallback:'/shell.html'// via dynamicUrlToDependenciesdynamicUrlToDependencies:{'/shell':['/shell.hbs']},navigateFallback:'/shell'

This comes in handy when used with a web application that performs client-side URL routingusing theHistory API. It allows anyarbitrary URL that the client generates to map to a fallback cached HTML entry. This fallback entryideally should serve as an "application shell" that is able to load the appropriate resourcesclient-side, based on the request URL.

Note: This isnot intended to be used to route failed navigations to ageneric "offline fallback" page. ThenavigateFallback page is used whether thebrowser is online or offline. If you want to implement an "offline fallback",then using an approach similar tothis exampleis more appropriate.

Default:''

Works to limit the effect ofnavigateFallback, so that the fallback onlyapplies to requests for URLs with paths that match at least oneRegExp.

This option is useful if you want to fallback to the cached App Shell forcertain specific subsections of your site, but not have that behavior applyto all of your site's URLs.

For example, if you would like to havenavigateFallback only apply tonavigation requests to URLs whose path begins with/guide/(e.g.https://example.com/guide/1234), the following configuration could beused:

navigateFallback:'/shell',navigateFallbackWhitelist:[/^\/guide\//]

If set to[] (the default), the whitelist will be effectively bypassed, andnavigateFallback will apply to all navigation requests, regardless of URL.

Default:[]

Replaces a specified string at the beginning of path URL's at runtime. Use thisoption when you are serving static files from a different directory at runtimethan you are at build time. For example, if your local files are underdist/app/ but your static asset root is at/public/, you'd strip 'dist/app/'and replace it with '/public/'.

Default:''

Configures runtime caching for dynamic content. If you use this option, thesw-toolboxlibrary configured with the caching strategies you specify will automatically be included inyour generated service worker file.

EachObject in theArray needs aurlPattern, which is either aRegExpor a string, following the conventions of thesw-toolbox library'srouting configuration. Also required isahandler, which should be either a string corresponding to one of thebuilt-in handlers under thetoolbox. namespace, or a function corresponding to your customrequest handler.Optionally,method can be added to specify one of thesupported HTTP methods (default:'get'). There is alsosupport foroptions, which corresponds to the same options supported by asw-toolbox handler.

For example, the following defines runtime caching behavior for two different URL patterns. It uses adifferent handler for each, and specifies a dedicated cache with maximum size for requeststhat match/articles/:

runtimeCaching:[{urlPattern:/^https:\/\/example\.com\/api/,handler:'networkFirst'},{urlPattern:/\/articles\//,handler:'fastest',options:{cache:{maxEntries:10,name:'articles-cache'}}}]

Thesw-precache +sw-toolbox explainer hasmore information about how and why you'd use both libraries together.

Default:[]

Controls whether or not the generated service worker will callskipWaiting()inside theinstall handler.

By default, when there's an update to a previously installedservice worker, then the new service worker delays activation and stays in awaiting state until all pages controlled by the old service worker areunloaded. CallingskipWaiting() allows a newly registered service worker tobypass thewaiting state.

WhenskipWaiting istrue, the new service worker'sactivate handler willbe called immediately, and any out of date cache entries from the previousservice worker will be deleted. Please keep this in mind if you rely on oldercached resources to be available throughout the page's lifetime, because, forexample, youdefer the loading of some resourcesuntil they're needed at runtime.

Default:true

An array of one or more string patterns that will be passed in toglob.All files matching these globs will be automatically precached by the generated service worker.You'll almost always want to specify something for this.

Default:[]

Removes a specified string from the beginning of path URL's at runtime. Use thisoption when there's a discrepancy between a relative path at build time andthe same path at run time. For example, if all your local files are underdist/app/ and your web root is also atdist/app/, you'd strip that prefixfrom the start of each local file's path in order to get the correct relativeURL.

Default:''

Maps multiple strings to be stripped and replaced from the beginning of URL paths at runtime.Use this option when you have multiple discrepancies between relative paths at build time andthe same path at run time.IfstripPrefix andreplacePrefix are not equal to'', they are automatically added to this option.

stripPrefixMulti:{'www-root/public-precached/':'public/','www-root/public/':'public/'}

Default:{}

The path to the (lo-dash) template used togenerateservice-worker.js. If you need to add additional functionality to thegenerated service worker code, it's recommended that you use theimportScripts option to include extra JavaScript rather thanusing a different template. But if you do need to change the basic generatedservice worker code, please make a copy of theoriginal template,modify it locally, and use this option to point to your template file.

Default:service-worker.tmpl (in the directory that this module lives in)

Determines whether there's log output for each individual static/dynamic resource that's precached.Even if this is set to false, there will be a final log entry indicating the total size of allprecached resources.

Default:false

While it's possible to use thesw-precache module's API directly within anyJavaScript environment, several wrappers have been developed by members of thecommunity tailored to specific build environments. They include:

• sw-precache-webpack-plugin
• sw-precache-brunch
• grunt-sw-precache
• exhibit-builder-sw-precache

There are also several starter kits or scaffolding projects that incorporatesw-precache into their build process, giving you a full service worker out ofthe box. The include:

• polymer-cli
• create-react-pwa

• react-redux-universal-hot-example
• Polymer Starter Kit
• Web Starter Kit

While there are not always ready-to-use wrappers for specific environments, this list contains some recipes to integratesw-precache in your workflow:

• Gradle wrapper for offline JavaDoc
• Brunch starter for Phoenix Framework

Thanks toSindre Sorhus andAddy Osmani for their advice and code reviews.Jake Archibald was kind enough to review the service worker logic.

Copyright © 2017 Google, Inc.

Licensed under theApache License, Version 2.0 (the "License");you may not use this file except in compliance with the License. You mayobtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, softwaredistributed under the License is distributed on an "AS IS" BASIS,WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.See the License for the specific language governing permissions andlimitations under the License.