⚠️sw-precache⚠️

sw-toolboxandsw-precacheare deprecated in favor of Workbox. Please readthis migration guide for information on upgrading.

About

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

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

The module can be used in JavaScript-based build scripts, like those written withgulp,and it also provides a command-line interface.You can use the module directly, or if you'd prefer, use one of thewrappers aroundsw-precachefor specific build environments, like webpack.

It can beused alongsidethesw-toolbox library, which works well when following the App Shell + dynamic content model.

The full documentation is in this README, and the getting started guideprovides a quicker jumping off point.

To learn more about the internals of the generated service worker, you can read this deep-dive byHuang Xuan.

Table of Contents

• 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

Install

Local build integration:

$ npm install --save-dev sw-precache

Global command-line interface:

$ npm install --global sw-precache

Usage

Overview

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

2. Incorporatesw-precacheinto yournode-based build script.It should work well with eithergulporGrunt,or other build scripts that run on node.In fact, we've provided examples of both in thedemo/directory. Each build script indemohas a function calledwriteServiceWorkerFile()that shows how to use the API. Both scripts generate fully-functional JavaScript code that takes care of precaching and fetching all the resources your site needs to function offline. There is also acommand-line interface available, for those using alternate build setups.

3. Register the service worker JavaScript.The JavaScript that's generated needs to be registered as the controlling service worker for your pages. This technically only needs to be done from within a top-level "entry" page for your site, since the registration includes ascope which will apply to all pages underneath your top-level page.service-worker-registration.jsis a sample script that illustrates the best practices for registering the generated service worker and handling the variouslifecycleevents.

Example

The project'ssamplegulpfile.jsillustrates the full use of sw-precache in context. (Note that the sample gulpfile.js is the one in thedemofolder, not the one in the root of the project.) You can run the sample by cloning this repo, usingnpm installto pull in the dependencies, changing to thedemo/directory, running`npm bin`/gulp serve-dist,and then visitinghttp://localhost:3000.

There's also asampleGruntfile.jsthat shows service worker generation in Grunt. 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 under appand that you'd like to cacheallyour 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 to registerbefore it can take control of your site's pages.service-worker-registration.jsis a ready-to- use script to handle registration.

Considerations

• Service worker caching should be considered a progressive enhancement. If you follow the model of conditionally registering a service worker only if it's supported (determined by if('serviceWorker' in navigator)), you'll get offline support on browsers with service workers and on 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-precacheto your build.

• Allresources that are precached will be fetched by a service worker running in a separate thread as soon as the service worker is installed. You should be judicious in what you list in the dynamicUrlToDependenciesandstaticFileGlobsoptions, since listing files that are non-essential (large images that are not shown on every page, for instance) will result in browsers downloading more data than is strictly necessary.

• Precaching doesn't make sense for all types of resources (see the previous point). Other caching strategies, like those outlined in theOffline Cookbook,can be used in conjunction withsw-precacheto provide the best experience for your users. If you do implement additional caching logic, put the code in a separate JavaScript file and include it using theimportScripts()method.

• sw-precacheuses acache-firststrategy, which results in a copy of any cached content being returned without consulting the network. A useful pattern to adopt with this strategy is to display a toast/alert to your users when there's new content available, and give them an opportunity to reload the page to pick up that new content (which the service worker will have added to the cache, and will be available at the next page load). The sampleservice-worker-registration.jsfileillustrates the service worker lifecycle event you can listen for to trigger this message.

Command-line interface

For those who would prefer not to usesw-precacheas part of agulpor Gruntbuild, there's acommand-line interfacewhich supports the options listedin the API, provided via flags or an external JavaScript configuration file.

Hypenated flags are converted to camelCaseoptions.
Options starting with--noprefix negate the boolean value. For example,--no-clients-claimsets the value ofclientsClaimtofalse.

Warning:When usingsw-precache"by hand", outside of an automated build process, it's your responsibility to re-run the command each time there's a change to any local resources! Ifsw-precache is 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 inside the top-level directory that contains your site's contents, and you'd like to generate a service-worker.jsfile that will automatically precache all of the local files, you can simply run

$ sw-precache

Alternatively, if you'd like to only precache.htmlfiles that live withindist/,which is a subdirectory 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 meanings to 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 via module.exports. For example, assume there's apath/to/sw-precache-config.jsfile 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 the verboseoption, via

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

This provides the most flexibility, such as providing a regular expression for theruntimeCaching.urlPatternoption.

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

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

Runtime Caching

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

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

API

Methods

Thesw-precachemodule exposes two methods:generateandwrite.

generate(options, callback)

generatetakes inoptions,generates a service worker from them and passes the result to a callback function, which must have the following interface:

callback(error, serviceWorkerString)

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

Since 2.2.0,generate()also returns a Promise.

write(filePath, options, callback)

writetakes inoptions,generates a service worker from them, and writes the service worker to a specified file. This method always invokescallback(error).If no error was found, theerrorparameter will benull

Since 2.2.0,write()also returns aPromise.

Options Parameter

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

cacheId [String]

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

Default:''

clientsClaim [Boolean]

Controls whether or not the generated service worker will call clients.claim() inside theactivatehandler.

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

Default:true

directoryIndex [String]

Sets a default filename to return for URL's formatted like directory paths (in other words, those ending in'/').sw-precachewill take that translation into account and serve the contents a relativedirectoryIndexfile when there's no other match for a URL ending in'/'.To turn off this behavior, setdirectoryIndextofalseornull.To override this behavior for one or more URLs, use thedynamicUrlToDependenciesoption to explicitly set up mappings between a directory URL and a corresponding file.

Default:'index.html'

dontCacheBustUrlsMatching [Regex]

It's very important that the requestssw-precachemakes to populate your cache result in the most up-to-date version of a resource at a given URL. Requests that are fulfilled with out-of-date responses (like those found in your browser's HTTP cache) can end up being read from the service worker's cache indefinitely. Jake Archibald'sblog post provides more context about this problem.

In the interest of avoiding that scenario,sw-precachewill, by default, append a cache-busting parameter to the end of each URL it requests when populating or updating its cache. Developers who are explicitly doing "the right thing" when it comes to setting HTTP caching headers on their responses might want to opt out of this cache-busting. For example, if all of your static resources already include versioning information in their URLs (via a tool like gulp-rev), and are served with long-lived HTTP caching headers, then the extra cache-busting URL parameter is not needed, and can be safely excluded.

dontCacheBustUrlsMatchinggives you a way of opting-in to skipping the cache busting behavior for a subset of your URLs (or all of them, if a catch-all value like/./is used). If set, then thepathname of 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 additional cache-busting URL parameter appended.

Note: Prior tosw-precachev5.0.0,dontCacheBustUrlsMatchingmatched against the entire request URL. As of v5.0.0, it only matches against the URL's pathname.

Default:not set

dynamicUrlToDependencies [Object⟨String,Buffer,Array⟨String⟩⟩]

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

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

Default:{}

handleFetch [boolean]

Determines whether thefetchevent handler is included in the generated service worker code. It is useful to set this tofalsein development builds, to ensure that features like live reload still work. Otherwise, the content would always be served from the service worker cache.

Default:true

ignoreUrlParametersMatching [Array⟨Regex⟩]

sw-precachefinds matching cache entries by doing a comparison with the full request URL. It's common for sites to support URL query parameters that don't affect the site's content and should be effectively ignored for the purposes of cache matching. One example is the utm_-prefixedparameters used for tracking campaign performance. By default,sw-precachewill ignorekey=valuewhenkeymatchesanyof the regular expressions provided in this option. To ignore all parameters, use[/./].To take all parameters into account when matching, use[].

Default:[/^utm_/]

importScripts [Array⟨String⟩]

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

Default:[]

logger [function]

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

Default:console.log

maximumFileSizeToCacheInBytes [Number]

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

Default:2097152(2 megabytes)

navigateFallback [String]

Sets an HTML document to use as a fallback for URLs not found in thesw-precachecache. This fallback URL needs to be cached viastaticFileGlobsordynamicUrlToDependenciesotherwise it won't work.

// via staticFileGlobs
staticFileGlobs:['/shell.html']
navigateFallback:'/shell.html'

// via dynamicUrlToDependencies
dynamicUrlToDependencies:{
'/shell':['/shell.hbs']
},
navigateFallback:'/shell'

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

Note:This isnotintended to be used to route failed navigations to a generic "offline fallback" page. ThenavigateFallbackpage is used whether the browser is online or offline. If you want to implement an "offline fallback", then using an approach similar tothis example is more appropriate.

Default:''

navigateFallbackWhitelist [Array⟨RegExp⟩]

Works to limit the effect ofnavigateFallback,so that the fallback only applies to requests for URLs with paths that match at least one RegExp.

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

For example, if you would like to havenavigateFallbackonly apply to navigation requests to URLs whose path begins with/guide/ (e.g.https://example.com/guide/1234), the following configuration could be used:

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

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

Default:[]

replacePrefix [String]

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

Default:''

runtimeCaching [Array⟨Object⟩]

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

EachObjectin theArrayneeds aurlPattern,which is either a RegExp or a string, following the conventions of thesw-toolboxlibrary's routing configuration.Also required is ahandler,which should be either a string corresponding to one of the built-in handlersunder thetoolbox.namespace, or a function corresponding to your custom request handler. Optionally,methodcan be added to specify one of thesupported HTTP methods(default:'get'). There is also support foroptions,which corresponds to the same options supported by a sw-toolboxhandler.

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

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

Thesw-precache+sw-toolboxexplainerhas more information about how and why you'd use both libraries together.

Default:[]

skipWaiting [Boolean]

Controls whether or not the generated service worker will call skipWaiting() inside theinstallhandler.

By default, when there's an update to a previously installed service worker, then the new service worker delays activation and stays in a waitingstate until all pages controlled by the old service worker are unloaded. CallingskipWaiting()allows a newly registered service worker to bypass thewaitingstate.

WhenskipWaitingistrue,the new service worker'sactivatehandler will be called immediately, and any out of date cache entries from the previous service worker will be deleted. Please keep this in mind if you rely on older cached resources to be available throughout the page's lifetime, because, for example, youdefer the loading of some resources until they're needed at runtime.

Default:true

staticFileGlobs [Array⟨String⟩]

An array of one or more string patterns that will be passed in to glob. 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:[]

stripPrefix [String]

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

Default:''

stripPrefixMulti [Object]

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 and the same path at run time. IfstripPrefixandreplacePrefixare not equal to'',they are automatically added to this option.

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

Default:{}

templateFilePath [String]

The path to the (lo-dash) template used to generateservice-worker.js.If you need to add additional functionality to the generated service worker code, it's recommended that you use the importScriptsoption to include extra JavaScript rather than using a different template. But if you do need to change the basic generated service 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)

verbose [boolean]

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 all precached resources.

Default:false

Wrappers and Starter Kits

While it's possible to use thesw-precachemodule's API directly within any JavaScript environment, several wrappers have been developed by members of the community 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 incorporate sw-precacheinto their build process, giving you a full service worker out of the box. The include:

CLIs

• polymer-cli
• create-react-pwa

Starter Kits

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

Recipes for writing a custom wrapper

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

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

Acknowledgements

Thanks toSindre Sorhusand Addy Osmanifor their advice and code reviews. Jake Archibaldwas kind enough to review the service worker logic.

License

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 may obtain a copy of the License at

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

Unless required by applicable law or agreed to in writing, software distributed 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 and limitations under the License.