Testing Your PWA (Progressive Web Application): A 2026 Guide
Last updated: October 2026
Quick answer
To test a Progressive Web Application (PWA), check six things: that the web app manifest makes the app installable, that the service worker registers and updates correctly, that offline and caching behavior work as designed, that push notifications respect permissions, that the layout works on every screen size, and that the core user journeys pass in every browser you support. Lighthouse no longer has a PWA category, so in 2026 you verify installability in Chrome DevTools and test offline and caching behavior with browser automation rather than relying on a single score.
What is a PWA, and why does it need its own testing?
A PWA is a website built with modern web capabilities so it can behave like an installed app: it can be added to a phone’s home screen or a desktop dock, open in its own window, keep working with a poor connection, and send notifications. Two technical pieces make this possible:
- The web app manifest, a JSON file that tells the browser the app’s name, icons, start URL and display mode.
- The service worker, a JavaScript file that sits between the page and the network. It can cache files, serve pages offline, and receive push messages.
Because the service worker can answer requests without touching the network, a PWA can show stale content, break after a deploy, or behave differently on a second visit than on the first. Standard functional testing on a fresh browser misses most of these problems. That is why PWAs need extra checks on top of normal web testing.
What changed in PWA testing since 2024
Older PWA checklists, including the first version of this article, leaned on Lighthouse’s PWA audit and its badge. Two changes make that advice out of date:
- Lighthouse dropped the PWA category. Google’s PageSpeed Insights release notes state that the update to Lighthouse 12.0 in May 2024 included “the removal of the PWA category.” Lighthouse still audits performance, accessibility, best practices and SEO, which remain useful for PWAs.
- Chrome relaxed its install criteria. Chrome removed the requirement for a service worker with a fetch handler for installing from the browser menu (Chrome 108 on mobile, 112 on desktop). Chrome notes that its automatic install prompt still looked for a fetch handler at the time, and that service workers remain necessary for caching, notifications and offline experiences.
The practical result: “installable” and “works offline” are now separate things to test. An app can install fine and still show a blank screen with no connection.
A PWA testing checklist for 2026
1. Manifest and installability
According to MDN, Chromium browsers (Chrome, Edge, Samsung Internet) expect the manifest to include name or short_name, icons at 192px and 512px, start_url, and display or display_override, and the app must be served over HTTPS (or localhost). Test that:
- The manifest loads without errors and every icon URL returns an image.
- The installed app opens at the right start URL, in the right display mode, with the right name and theme color.
- Install works on each platform you care about. Install behavior differs by browser: MDN notes that Safari on iOS 16.4 and later lets users add web apps from the Share menu, Safari 17 on macOS supports Add to Dock, and Firefox on Windows (version 143 and later) can pin sites to the taskbar as web apps, though its support for manifest features is more limited than Chromium’s.
2. Service worker lifecycle
- The service worker registers on first visit and controls the page after reload.
- After you deploy a new version, users actually receive it. Check how the app handles a waiting service worker: does it prompt to refresh, or update silently on next launch?
- Nothing breaks when the service worker is unregistered or storage is cleared.
3. Offline behavior and caching
- Load key pages, go offline, and reload. You should see either cached content or a clear offline page, never the browser’s default error.
- Actions taken offline (form submissions, cart updates) are either queued and sent later or clearly blocked with a message.
- Cached content does not go stale: prices, account data and other dynamic content should come from the network when it is available.
- Cache size stays reasonable and old caches are cleaned up after updates.
4. Push notifications
- The permission prompt appears only after a user action, not on page load. On Apple devices this is required: WebKit explains that from iOS and iPadOS 16.4, web push works for web apps added to the Home Screen, and permission must be requested in response to a direct user interaction.
- Notifications arrive, display correctly, and open the right screen when tapped.
- Denying permission does not break the app, and users can unsubscribe.
5. Responsiveness and cross-browser behavior
- Layouts work from small phones to wide desktop windows, including the installed standalone window, which has no browser address bar.
- Core journeys pass in Chrome, Edge, Firefox and Safari, since PWA features vary by browser.
- Pages stay fast. Lighthouse performance and accessibility audits still apply.
6. Core functionality and regression
A PWA is still a web app. Sign-up, login, search, checkout and other business flows need the same functional and regression testing as any site, run on every release.
Tools for testing PWAs
| What you are testing | Useful tools | Notes |
|---|---|---|
| Manifest and installability | Chrome DevTools Application panel, PWABuilder | DevTools shows an Installability section listing errors in the manifest. |
| Service worker, offline, cache | Chrome DevTools, Playwright | DevTools can toggle offline, bypass the service worker and inspect Cache Storage. |
| Push and background sync | Chrome DevTools, real devices | DevTools can simulate a push event; real devices confirm delivery. |
| Performance, accessibility, SEO | Lighthouse, PageSpeed Insights | No PWA category since Lighthouse 12. |
| Real devices and browsers | Device clouds such as TestMu AI (formerly LambdaTest), Appium | Needed for iOS home-screen and Android install behavior. |
| End-to-end business flows | Codeless tools such as CloudQA, Selenium, Playwright | Run on every build and across browsers. |
Chrome DevTools
The Application panel is the main replacement for the old Lighthouse PWA audit. It shows the parsed manifest and installability errors, lets you put the service worker offline, force it to update on reload, bypass it for the network, emulate push and background sync events, inspect Cache Storage, and clear all storage in one click.
Playwright
For automated service worker tests, Playwright can capture requests made by service workers and tell you whether a response came from the service worker. Its docs note that service worker support is limited to Chromium-based browsers.
PWABuilder
Microsoft’s PWABuilder report card checks a URL’s manifest and service worker and can package a PWA for app stores.
Supporting tools
Mock APIs help you simulate slow or failed backends while testing offline handling; try the free Mock API tool. The Website Analyzer runs Lighthouse-style performance checks, and the Visual Regression tool catches layout shifts between releases. For more device options, see our guide to tools to test mobile websites.
How to fit PWA testing into your release process
- Automate the core journeys and run them on every build and on a schedule.
- Add targeted service worker tests for offline, update and cache behavior where your team writes code-based tests.
- Do a manual install and push pass on real iOS and Android devices before major releases, because install and notification behavior varies by platform.
- Watch production. A bad service worker can keep serving a broken version until it updates, so monitor key journeys on the live site after each deploy.
Testing PWA user journeys with CloudQA
CloudQA is a codeless test automation platform for web applications, which covers the “core functionality and regression” part of PWA testing. You record a journey in the browser with the CloudQA Chrome extension, then edit it visually: add assertions, waits, variables, data sets, or custom JavaScript steps where a check needs code. Tests are stored as reusable modules.
- Cross-browser runs: tests run in the CloudQA cloud on Chrome, Firefox and Edge, in parallel, on a schedule or from CI/CD through the CloudQA APIs. See running tests across browsers, environments and schedules.
- Deterministic execution: recorded steps run exactly as written. Self-healing only starts when a step fails because its element cannot be found, and the recovery is reported for review.
- Modern front ends: CloudQA handles Shadow DOM, iframes and automatic waits for page loads and AJAX, which PWAs built on component frameworks often use.
- Production checks: with synthetic monitoring, recorded journeys are replayed on a schedule against the live site.
CloudQA does not replace DevTools or device testing for install prompts and push delivery; use them together. You can start a free account, compare regression testing features, or request a demo. If you would rather hand off the work, CloudQA also offers managed testing services.
Frequently Asked Questions
Does Lighthouse still have a PWA audit?
No. Lighthouse 12.0, rolled out to PageSpeed Insights in May 2024, removed the PWA category. Use the Manifest and Service Workers sections of the Chrome DevTools Application panel to check installability and offline behavior instead.
Does a PWA need a service worker to be installable?
Not in Chrome when installing from the browser menu; Chrome removed that requirement in version 108 on mobile and 112 on desktop. You still need a service worker for offline support, caching and push notifications.
How do I test a PWA offline?
Load the app, then use the Offline checkbox in the Chrome DevTools Application panel (or an automation tool such as Playwright) and reload key pages. Each page should show cached content or a clear offline message, and offline actions should be queued or blocked with a message.
Can I test PWA push notifications on iPhone?
Yes, on iOS and iPadOS 16.4 or later, but only after the web app is added to the Home Screen. Permission must be requested after a user action, such as tapping a subscribe button, so test on a real device.
Which tools are best for testing a PWA?
Combine Chrome DevTools for manifest and service worker checks, Lighthouse for performance and accessibility, a real-device cloud for install behavior, and an automation tool such as CloudQA, Playwright or Selenium for regression testing of core user journeys.