# pwa-wp: giving WordPress one service worker instead of thirty > The PWA plugin from GoogleChromeLabs is a feature plugin that brings service workers, web app manifests and HTTPS handling to WordPress, and it exists to be merged into core piece by piece rather than to replace the plugins that already ship their own. It suits a theme or plugin author who needs PWA building blocks without fighting every other PWA plugin on the same site. **GoogleChromeLabs/pwa-wp** — WordPress feature plugin to bring Progressive Web Apps (PWA) to Core - Repository: https://github.com/GoogleChromeLabs/pwa-wp - Website: https://wordpress.org/plugins/pwa/ - Stars: 631 · Forks: 94 - Language: PHP - License: GPL-2.0 - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/googlechromelabs-pwa-wp ## One service worker, because only one can win The PWA plugin is a WordPress feature plugin to bring Progressive Web App capabilities to Core, and the problem it solves is stated with unusual clarity in the readme. It is not intended to obsolete the other plugins and themes which turn WordPress sites into PWAs. It is intended to provide the PWA building blocks and the coordination mechanism so that those themes and plugins do not reinvent the wheel and do not conflict with each other. The concrete conflict is this: only one service worker can be active at a time. If a theme implements the app shell model and a plugin provides push notifications, and each ships its own service worker, one of them wins and the other breaks. The plugin's answer is that a theme implementing the app shell model should be able to extend the core service worker, and a plugin providing push notifications should be able to do the same. The readme makes the recommendation explicit: if you are developing a plugin or theme that includes a service worker, consider relying on this PWA plugin, or at least only use the built-in implementation as a fallback for when the PWA plugin is not available. That is the design decision worth understanding before anything else. This is infrastructure for extending, not a turnkey PWA solution for a site, and a team that expects to install it and get an installable app on the home screen will be disappointed. ## A staging ground for core, with HTTPS already merged The plugin serves as a place to implement support for these technologies in WordPress with the intention of being proposed for core merge, piece by piece. And the case is not hypothetical: the readme notes that the HTTPS functionality from this plugin has largely been made part of Core, pointing at improved HTTPS detection and migration in WordPress 5.7. That is the most important fact about this repository for an adopter. The plugin is a staging ground where features are built in the open, in a public repository with public pull requests, and then proposed to WordPress Core. The HTTPS piece already made the journey. So the audience is two groups, and they want different things. The first is the WordPress core contributor, for whom this repository is where a language-level or behaviour-level change gets drafted. The second is the plugin or theme author, who wants the PWA building blocks today and does not want to implement a service worker from scratch or conflict with somebody else who already did. The listed contributors are telling for the first group. The readme credits profiles from google, xwp, rtcamp, westonruter and albertomedina, which is a mix of a Google team, a WordPress core contributor, a hosting company, a core committer and an agency. The project is developed on GitHub, pull requests are welcome, and the readme asks people to check the issues reported on GitHub before going to the plugin forum. The licence is GPLv2 or later, the plugin is on wordpress.org/plugins/pwa/, and the readme is marked as tested up to WordPress 6.7 with a stable tag of 0.8.2. ## Caching strategies, off by default until version 0.6 The behaviour of the service worker has changed over the life of the plugin, and the history explains the shape of the current configuration. In versions prior to 0.6, no caching strategies were added by default. The only service worker behaviour was to serve an offline template when the client's connection is down or the site is down, and to serve an error page when the server returns a 500 Internal Server Error. As of 0.6, there is a new Offline browsing toggle on the Reading Settings screen in the admin. That toggle is disabled by default, and when enabled it registers a network-first caching strategy for navigations, so that the offline page is not shown when accessing previously accessed pages. The network-first strategy is also used for assets from themes, plugins and WordPress core. Uploaded images get served with a stale-while-revalidate strategy. The readme links the pull request for the details of these changes. The design choice here is a conservative one and the reasoning is sound. A caching strategy registered on a site's navigations affects every page load for every visitor, and a stale cache that serves the wrong version of a page is a worse failure than a page that fails to load. Leaving the toggle off by default means a site opts into caching deliberately, and the site owner is the one who decides whether a network-first strategy is right for their content. The cost is that a site that installs the plugin and does nothing gets an offline template and an error page, and nothing else. Anyone expecting install-and-go caching will find the toggle, if they read the notes. ## The build and test tooling behind the plugin The repository is a PHP plugin with a JavaScript toolchain, and the package.json gives a clear picture of how it is developed. The build is Grunt based, with a Gruntfile.js at the root, and the scripts section shows the shape of the workflow: ```json "build": "grunt build; grunt create-build-zip", "check-engines": "wp-scripts check-engines", "check-licenses": "wp-scripts check-licenses --production", "deploy": "grunt deploy", "lint": "npm-run-all --parallel lint:*", "lint:php": "vendor/bin/phpcs", "lint:php:fix": "./bin/phpcbf.sh", ``` Linting is split by language, with wp-scripts lint-js for the JavaScript, phpcs through vendor/bin for the PHP, and a separate check for the package.json. The check-licenses script is the interesting one for a plugin that will be distributed through wordpress.org, since it verifies the licences of the production dependencies. The dependency list is the standard WordPress stack rather than anything exotic. @wordpress/env at 10.7.0 is the local development environment, @wordpress/scripts at 29.0.0 provides the lint and test commands, eslint 8.57.1 with the WordPress plugin and a set of import and jsdoc rules does the JavaScript linting, and prettier 3.3.3 handles formatting. The one entry that stands out is workbox-cli at 7.3.0, which is the Workbox build tool that generates the service worker, and it is the clearest evidence that the service worker is generated from a configuration rather than hand-written. On the PHP side the tree carries composer.json and composer.lock, a phpstan.neon.dist for static analysis, a phpunit.xml.dist and a .phpcs.xml.dist for the coding standard, plus an .eslintrc and a .jshintignore for the JavaScript side. There is a .wp-env.json for the local environment, a bin/ directory holding the phpcbf script, a bundled-theme-support/ directory, an integrations/ directory, wp-admin/ and wp-includes/ directories, and a .wordpress-org/ directory holding the assets used on the plugin directory page. ## Where pwa-wp is the wrong choice The first limitation is that it is a WordPress plugin and nothing else. The PWA concepts it implements, service workers, web app manifests and HTTPS, are platform features, and if your application is not WordPress, this repository has nothing for you. The second is that it is a plugin rather than a site configuration, which means the person who installs it is not necessarily the person who can change its behaviour. The service worker is generated by Workbox, and extending it, in the way the readme recommends for theme and plugin authors, means writing against an internal extension point of a plugin that is explicitly on a path into core. The extension point may move when the code merges into core, and the readme does not describe a stability guarantee for it. The third is the pacing. The last push was on 2026-06-15, the newest published release is 0.8.2 from 2024-11-11, and the previous ones are 0.8.1 from 2024-04-02 and 0.8.0 from 2024-01-24. So the release tags stopped moving about two years ago while the repository kept receiving commits, and the plugin is marked as tested up to WordPress 6.7. For a plugin that automates updates and that touches how every request is served, a release cadence that has stopped is a genuine risk to weigh. The fourth is that the plugin is deliberately not the whole answer. It does not provide the app shell, the offline experience or the installability that a site wants; it provides the machinery and expects a theme or plugin to build on it. A site owner who wants a PWA and is not writing a theme or plugin is better served by one of the existing PWA plugins, and the readme says so. The fifth is the caching story for a site with dynamic content. A network-first strategy for navigations is a reasonable default for a content site, and the offline template covers the connection failure case. A site where the logged-in experience matters is a different problem, because a cached authenticated page is a security question rather than a performance one, and the readme does not address it. ## Conclusion pwa-wp fits a WordPress theme or plugin author who needs PWA support and does not want to fight the other PWA plugin on the same installation, since the plugin exists precisely to provide shared building blocks and a coordination mechanism rather than to be one more competing service worker. It is the wrong choice for a site that only needs a web app manifest and nothing else, and it is the wrong choice if you need a PWA setup outside WordPress. Before installing it, read the FAQ on the project wiki, decide whether you want the default service worker behaviour or your own, and note that the last push was on 2026-06-15 with the newest published release being 0.8.2 from 2024-11-11. ## FAQ ### What does the pwa-wp plugin do? It is a WordPress feature plugin that brings Progressive Web App capabilities to Core, providing service worker support, web app manifest support and HTTPS handling, with the intent of being proposed for core merge piece by piece. ### Why should a theme or plugin use the pwa-wp service worker? Because only one service worker can be active at a time, so a theme and a plugin that each create their own conflict. The plugin is intended to provide the PWA building blocks and a coordination mechanism so they can extend the core service worker instead, with the built-in implementation as a fallback when the plugin is not installed. ### Does pwa-wp add caching by default? Not before version 0.6, which added an Offline browsing toggle on the Reading Settings screen in the admin. It is disabled by default, and when enabled it registers a network-first strategy for navigations and theme, plugin and core assets, with uploaded images served stale-while-revalidate. ### How is the pwa-wp service worker built? The package.json devDependencies include workbox-cli, the Workbox build tool that generates the service worker from a configuration, and the Grunt build targets are invoked through the build script, grunt build followed by grunt create-build-zip. ### What licence is pwa-wp released under and how active is it? GPLv2 or later, with the plugin published on wordpress.org/plugins/pwa/ and marked as tested up to WordPress 6.7 with a stable tag of 0.8.2. The last push to the repository was on 2026-06-15 and the newest release tag, 0.8.2, dates from 2024-11-11. ## Sources - [GoogleChromeLabs/pwa-wp on GitHub](https://github.com/GoogleChromeLabs/pwa-wp) - [License: GPL-2.0](https://github.com/GoogleChromeLabs/pwa-wp/blob/develop/LICENSE) - [Project website](https://wordpress.org/plugins/pwa/) - [README](https://github.com/GoogleChromeLabs/pwa-wp/blob/develop/README.md) - [Releases](https://github.com/GoogleChromeLabs/pwa-wp/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/googlechromelabs-pwa-wp