A practical bar for Progressive Web Apps

Progressive Web Apps promise the reach of the web with the capabilities of a platform-specific app, using modern APIs to deliver enhanced reliability and installability across all devices from one codebase. The practical question is what separates an app that merely meets the technical definition from one that users actually want to keep. The core checklists below cover the essential behaviors every installable, usable PWA should meet.

Performance that users can feel

An app that loads slowly will struggle to retain users regardless of its features. The relationship between load time and bounce rate is stark: going from one second to ten seconds of load time raises the probability of a user bouncing by 123%. But fast startup alone is not enough. An app's responsiveness matters throughout its lifetime, whether that means a button click that visibly registers or scrolling and animation that never stutter.

There is no universal performance target, but the Lighthouse performance audits are built around the Core Web Vitals metrics. Scoring well on those is a good predictor of whether users will have a smooth experience. For real-world field data, PageSpeed Insights and the Chrome User Experience Report are the tools to use.

Browsers first, benefits second

Before a PWA is installed, it is a website that must work in any browser the user chooses. That means building for the widest possible range of browsers and devices, not just the most capable ones. As Jeremy Keith argues in Resilient Web Design, the effective approach is to identify the core features, implement them with the simplest possible technology, and then layer enhancements on top.

A form submission is a classic example. Start with a plain HTML form that sends a POST request. That works everywhere. Then add JavaScript-powered validation and AJAX submission for users whose browsers support it. Feature detection, rather than assumption, is what keeps the experience usable across today's and tomorrow's browsers.

Layouts for every viewport

Users will access a PWA on a phone, a desktop, and everything in between, and they may resize the window on the same device. Content and features need to be available at every viewport size, not just the one used during development. Rearranging the layout is fine; losing access to tasks or content is not.

Designing from small screens upward tends to produce better results across the board. As Luke Wroblewski puts it in Mobile First:

"Mobile devices require software development teams to focus on only the most important data and actions in an application. There simply isn't room in a 320 by 480 pixel screen for extraneous, unnecessary elements. You have to prioritize."

Approaching the layout from the content outward, rather than moving from a desktop wireframe down, is another practical way to protect this requirement.

Offline that respects the user

A platform-specific app does not present a blank page or an error screen when the connection drops, and neither should a PWA. Installed apps are expected to keep working without a connection, so falling back to the browser's default offline page breaks that expectation and the sense that the app belongs on the device.

The straightforward fix is to precache a custom offline page during the service worker's install event. That page shows when a user navigates to an uncached URL or attempts a feature that requires connectivity. Without a fallback page, Chrome still shows a basic offline page, but a custom one is a better fit for the app's own UX.

Installability matters beyond appearance

When a PWA is installed, it launches from the same place as other apps, runs in its own window, and appears in the task list. That parity with platform-specific apps is precisely what drives engagement. Users who install a PWA are its most invested audience, returning more often, staying longer, and converting at higher rates than ordinary visitors. Installability is therefore not just a cosmetic feature but a way to deepen the relationship with the most active users.

Beyond the baseline: what separates good PWAs from great ones

The core PWA checklist gets you a fast, reliable, and installable web app. However, to compete with the best native apps, there are deeper requirements that distinguish a truly solid PWA. These center on making the experience feel native to the device while leveraging the unique strengths of the web, such as search discoverability.

Working without an internet connection

Beyond a branded offline page, your app should be fully functional when connectivity is not an option. This means users should have access to relevant data and features at all times. For example, travel apps should make itineraries and boarding passes available, media apps should support offline playback, and news feeds should cache recent content. A core part of this expectation is that the user's authentication state remains intact.

To achieve this, you need to make your content adaptable to an offline context. The in-browser NoSQL database IndexedDB can store and retrieve data, while background sync can queue user actions and defer server communications until a stable connection is restored. Other content types, such as images and video, can be handled via service workers, which also enable safe, long-lived sessions for authentication. During these network transitions, skeleton screens can provide a sense of speed and placeholders that gracefully fall back to cached data when the connection drops.

Ensuring accessibility for all users

All interactions should meet the latest Web Content Accessibility Guidelines (WCAG). Since almost everyone will at some point interact with an app under circumstances covered by WCAG, designing for this spectrum of ability—whether permanent or temporary—makes the product more usable for everyone. The W3C's Introduction to Web Accessibility is a solid starting reference. While manual testing is the majority of the work, automated tools like the Lighthouse accessibility audit, axe, and Accessibility Insights can catch many issues. A best practice is to build on semantic elements like <a> and <button> rather than recreating them, ensuring that more advanced features still meet expectations for interaction patterns. Resources like the A11Y Nutrition Cards provide further advice for common components.

Leveraging search for discoverability

A key web advantage is being found via search, which drives the majority of website traffic. Therefore, making sure the app can be indexed and that canonical URLs exist for content is vital, especially when using client-side rendering.

First, ensure each URL has a unique, descriptive title and meta description. To identify and fix indexing problems, you can then use tools like the Google Search Console and the SEO audits in Lighthouse. Site owner tools from Bing and Yandex also provide support. You can also enhance your PWA's search presence with structured data based on schemas from Schema.org.

Supporting all input methods

Users should be able to operate the app fluidly with a mouse, keyboard, stylus, or touch. These input methods should not be tied to screen size; large viewports should support touch, and small viewports should support keyboard and mouse input. Where appropriate, you should also implement input-specific conveniences like pull-to-refresh.

The Pointer Events API provides a unified interface to handle various input types, which is particularly useful for stylus support. To ensure proper touch and keyboard functionality, rely on the correct native semantic elements rather than custom-built ones. Similarly, any interactions that are triggered by mouseover should also be activatable through a click or tap.

Putting permission requests in context

Requests for powerful APIs like notifications, geolocation, or credentials should only appear when needed, and always with context. Triggering these prompts, for instance on page load, makes users less likely to trust and accept them. Instead, offer a clear rationale right before the native prompt appears. The Permission UX article and UX Planet's The Right Ways to Ask Users for Permissions offer useful design guidance that applies across platforms.

Prioritizing a healthy codebase

A well-maintained codebase simplifies meeting all other goals. This involves several high-priority checks:

  • Avoid dependencies with known vulnerabilities.
  • Eliminate usage of deprecated APIs.
  • Remove unsafe coding patterns such as document.write() or non-passive scroll event listeners.
  • Code defensively so the app won't fail if third-party libraries, like analytics, are slow or fail to load.
  • Integrate static code analysis (linting) and automated testing across multiple browsers and release channels to catch issues before they reach production.

Adopting these practices makes your PWA robust and ready for future improvements.