What a PWA actually is
A Progressive Web App is not a separate technology so much as a set of practices applied to an ordinary website: a service worker for offline behavior and caching, a web app manifest describing how the app should look when installed, and a commitment to being served securely over HTTPS. There's no special framework required — an existing site can become progressive in stages, which is part of why the term is useful.
The payoff is a site that behaves more like a native app without the overhead of building and maintaining one: it can be added to a home screen, it can load instantly from cache on repeat visits, and it can keep working, at least partially, without a network connection.
It's also worth being clear about what a PWA is not. It isn't a shortcut to native performance for every kind of app, and it doesn't remove the need to think carefully about caching, updates, and storage limits. What it offers is a well-supported, standards-based way to close some of the gap between a website and an installed app, using tools that already ship in every modern browser.
The three pieces that make it work
- The manifest file. A small JSON file that tells the browser the app's name, icons, theme color, and how it should launch — full-screen, standalone, or in a browser tab.
- The service worker. A script that runs separately from the page and can intercept network requests, serve cached responses, and enable offline functionality.
- HTTPS. Service workers only run on secure origins, which also happens to be good practice regardless.
None of these pieces are large on their own, but they interact in ways that are easy to get wrong the first time — particularly caching strategy, which determines whether users see stale content or a blank screen when offline.
Deciding if it's worth building
A PWA earns its complexity when users return to a site often, when a reliable offline experience matters, or when installability genuinely changes how people use the product — a tool used daily, for example, benefits far more than a site visited once for a single article.
A minimal caching strategy to start with
For most content sites, a reasonable starting point is a network-first strategy for HTML — always try the network, fall back to cache — paired with a cache-first strategy for static assets like fonts and images, which change rarely and benefit most from instant loading.
Common pitfalls when adding a service worker
The most frequent mistake teams make when adopting service workers is caching too aggressively, too early. An overly broad cache-first strategy can cause users to see outdated content long after a page has been updated, with no obvious way to force a refresh. Starting with a conservative strategy — caching only static assets that rarely change, and leaving HTML on a network-first policy — avoids most of the confusing bugs that give PWAs a bad reputation among teams that tried them once and gave up.
It's also worth testing the offline experience deliberately, not just assuming it works because a service worker is registered. Turning off the network in developer tools and walking through the site's core flows will surface gaps quickly — a blank screen instead of a friendly offline message is a common and avoidable failure.
Summary
- What a PWA actually is
- The three pieces that make it work
- Deciding if it's worth building
- Common pitfalls when adding a service worker
Frequently asked questions
Do I need to rebuild my site to add PWA features?
No. A service worker and manifest can be layered onto an existing site without changing the underlying architecture.
Will a PWA appear in app stores?
Some platforms allow PWAs to be listed, but the core benefit — install to home screen, offline support — works directly from the browser without a store.
Is offline support required for something to count as a PWA?
Not strictly, but a service worker with at least basic caching is expected, since it's what enables reliability on flaky connections.