A basic understanding of the following:
\n\nThe ngsw-config.json configuration file specifies which files and data URLs the Angular service\nworker should cache and how it should update the cached files and data. The Angular CLI\nprocesses the configuration file during ng build. Manually, you can process it with the\nngsw-config tool (where <project-name> is the name of the project being built):
The configuration file uses the JSON format. All file paths must begin with /, which corresponds\nto the deployment directory—usually dist/<project-name> in CLI projects.
Unless otherwise noted, patterns use a limited glob format:
\n** matches 0 or more path segments.* matches 0 or more characters excluding /.? matches exactly one character excluding /.! prefix marks the pattern as being negative, meaning that only files that don't match the pattern will be included.Example patterns:
\n/**/*.html specifies all HTML files./*.html specifies only HTML files in the root.!/**/*.map exclude all sourcemaps.Each section of the configuration file is described below.
\nappDatalinkThis section enables you to pass any data you want that describes this particular version of the app.\nThe SwUpdate service includes that data in the update notifications. Many apps use this section to provide additional information for the display of UI popups, notifying users of the available update.
indexlinkSpecifies the file that serves as the index page to satisfy navigation requests. Usually this is /index.html.
assetGroupslinkAssets are resources that are part of the app version that update along with the app. They can include resources loaded from the page's origin as well as third-party resources loaded from CDNs and other external URLs. As not all such external URLs may be known at build time, URL patterns can be matched.
\nThis field contains an array of asset groups, each of which defines a set of asset resources and the policy by which they are cached.
\nWhen the ServiceWorker handles a request, it checks asset groups in the order in which they appear in ngsw-config.json.\nThe first asset group that matches the requested resource handles the request.
It is recommended that you put the more specific asset groups higher in the list.\nFor example, an asset group that matches /foo.js should appear before one that matches *.js.
Each asset group specifies both a group of resources and a policy that governs them. This policy determines when the resources are fetched and what happens when changes are detected.
\nAsset groups follow the Typescript interface shown here:
\nnamelinkA name is mandatory. It identifies this particular group of assets between versions of the configuration.
installModelinkThe installMode determines how these resources are initially cached. The installMode can be either of two values:
prefetch tells the Angular service worker to fetch every single listed resource while it's caching the current version of the app. This is bandwidth-intensive but ensures resources are available whenever they're requested, even if the browser is currently offline.
lazy does not cache any of the resources up front. Instead, the Angular service worker only caches resources for which it receives requests. This is an on-demand caching mode. Resources that are never requested will not be cached. This is useful for things like images at different resolutions, so the service worker only caches the correct assets for the particular screen and orientation.
Defaults to prefetch.
updateModelinkFor resources already in the cache, the updateMode determines the caching behavior when a new version of the app is discovered. Any resources in the group that have changed since the previous version are updated in accordance with updateMode.
prefetch tells the service worker to download and cache the changed resources immediately.
lazy tells the service worker to not cache those resources. Instead, it treats them as unrequested and waits until they're requested again before updating them. An updateMode of lazy is only valid if the installMode is also lazy.
Defaults to the value installMode is set to.
resourceslinkThis section describes the resources to cache, broken up into the following groups:
\nfiles lists patterns that match files in the distribution directory. These can be single files or glob-like patterns that match a number of files.
urls includes both URLs and URL patterns that will be matched at runtime. These resources are not fetched directly and do not have content hashes, but they will be cached according to their HTTP headers. This is most useful for CDNs such as the Google Fonts service.
\n(Negative glob patterns are not supported and ? will be matched literally; i.e. it will not match any character other than ?.)
cacheQueryOptionslinkThese options are used to modify the matching behavior of requests. They are passed to the browsers Cache#match function. See MDN for details. Currently, only the following options are supported:
ignoreSearch: Ignore query parameters. Defaults to false.dataGroupslinkUnlike asset resources, data requests are not versioned along with the app. They're cached according to manually-configured policies that are more useful for situations such as API requests and other data dependencies.
\nThis field contains an array of data groups, each of which defines a set of data resources and the policy by which they are cached.
\nWhen the ServiceWorker handles a request, it checks data groups in the order in which they appear in ngsw-config.json.\nThe first data group that matches the requested resource handles the request.
It is recommended that you put the more specific data groups higher in the list.\nFor example, a data group that matches /api/foo.json should appear before one that matches /api/*.json.
Data groups follow this Typescript interface:
\nnamelinkSimilar to assetGroups, every data group has a name which uniquely identifies it.
urlslinkA list of URL patterns. URLs that match these patterns are cached according to this data group's policy. Only non-mutating requests (GET and HEAD) are cached.
\n? is matched literally; that is, it matches only the character ?.versionlinkOccasionally APIs change formats in a way that is not backward-compatible. A new version of the app may not be compatible with the old API format and thus may not be compatible with existing cached resources from that API.
\nversion provides a mechanism to indicate that the resources being cached have been updated in a backwards-incompatible way, and that the old cache entries—those from previous versions—should be discarded.
version is an integer field and defaults to 1.
cacheConfiglinkThis section defines the policy by which matching requests will be cached.
\nmaxSizelink(required) The maximum number of entries, or responses, in the cache. Open-ended caches can grow in unbounded ways and eventually exceed storage quotas, calling for eviction.
\nmaxAgelink(required) The maxAge parameter indicates how long responses are allowed to remain in the cache before being considered invalid and evicted. maxAge is a duration string, using the following unit suffixes:
d: daysh: hoursm: minutess: secondsu: millisecondsFor example, the string 3d12h will cache content for up to three and a half days.
timeoutlinkThis duration string specifies the network timeout. The network timeout is how long the Angular service worker will wait for the network to respond before using a cached response, if configured to do so. timeout is a duration string, using the following unit suffixes:
d: daysh: hoursm: minutess: secondsu: millisecondsFor example, the string 5s30u will translate to five seconds and 30 milliseconds of network timeout.
strategylinkThe Angular service worker can use either of two caching strategies for data resources.
\nperformance, the default, optimizes for responses that are as fast as possible. If a resource exists in the cache, the cached version is used, and no network request is made. This allows for some staleness, depending on the maxAge, in exchange for better performance. This is suitable for resources that don't change often; for example, user avatar images.
freshness optimizes for currency of data, preferentially fetching requested data from the network. Only if the network times out, according to timeout, does the request fall back to the cache. This is useful for resources that change frequently; for example, account balances.
You can also emulate a third strategy, staleWhileRevalidate, which returns cached data (if available), but also fetches fresh data from the network in the background for next time.\nTo use this strategy set strategy to freshness and timeout to 0u in cacheConfig.
This will essentially do the following:
\ncacheQueryOptionslinkSee assetGroups for details.
\nnavigationUrlslinkThis optional section enables you to specify a custom list of URLs that will be redirected to the index file.
\nThe ServiceWorker will redirect navigation requests that don't match any asset or data group to the specified index file. A request is considered to be a navigation request if:
navigation.text/html response (as determined by the value of the Accept header).By default, these criteria are:
\n.) in the last path segment.__.To configure whether navigation requests are sent through to the network or not, see the navigationRequestStrategy section.
\nWhile these default criteria are fine in most cases, it is sometimes desirable to configure different rules. For example, you may want to ignore specific routes (that are not part of the Angular app) and pass them through to the server.
\nThis field contains an array of URLs and glob-like URL patterns that will be matched at runtime. It can contain both negative patterns (i.e. patterns starting with !) and non-negative patterns and URLs.
Only requests whose URLs match any of the non-negative URLs/patterns and none of the negative ones will be considered navigation requests. The URL query will be ignored when matching.
\nIf the field is omitted, it defaults to:
\nnavigationRequestStrategylinkThis optional property enables you to configure how the service worker handles navigation requests:
\nPossible values:
\n'performance': The default setting. Serves the specified index file, which is typically cached.'freshness': Passes the requests through to the network and falls back to the performance behavior when offline.\nThis value is useful when the server redirects the navigation requests elsewhere using an HTTP redirect (3xx status code).\nReasons for using this value include:
The freshness strategy usually results in more requests sent to the server, which can increase response latency.\nIt is recommended that you use the default performance strategy whenever possible.