Someone lands on your site from a search result, uses it twice, and never thinks about it again. That is the normal web.
A progressive web app changes the second half of that. It can be added to a home screen, opened without a browser bar, and made to work when the connection drops. No app store, no separate codebase, no download of forty megabytes before anything happens.
Progressive web app development is the work of adding those capabilities to a site you already have. It is less dramatic than building a native app and, for a great many businesses, it is the more sensible option.
Progressive Web App Development (PWA): A Comprehensive Guide
What actually makes a site a PWA
Three technical requirements, and one that gets forgotten.
- HTTPS. Service workers only run on secure connections, so this is a prerequisite rather than a recommendation.
- A web app manifest. A small JSON file naming the app, its icons, its start URL and how it should display. This is what allows installation to a home screen.
- A service worker. A script running separately from the page that can intercept network requests, serve cached responses and enable offline behaviour. This is the substantial piece.
- Responsive design that already works. The forgotten one. A PWA wrapper around a site that is awkward on a phone produces an awkward app on a phone.
Building one, in order
Start by making the underlying site fast and responsive. Everything a PWA adds sits on top of that, and none of it compensates for a slow page.
Add HTTPS if it is not already there, then write the manifest. Icons at the required sizes, a sensible display mode, a start URL that makes sense as a landing point.
Then the service worker, which is where the real decisions are. Register it, define what gets cached, and decide the strategy for each type of resource. Application shell and static assets can be cached aggressively. Content that changes should go to the network first and fall back to cache. Anything personalised or transactional generally should not be cached at all.
Test the offline behaviour deliberately. Turn the connection off and use the thing. Broken offline states are worse than no offline support, because the interface promises something it cannot deliver.
The web.dev progressive web apps documentation covers the implementation detail thoroughly.
Caching is where PWAs go wrong
This deserves its own warning, because it is the most common failure and the least obvious.
A service worker that caches too eagerly will serve stale content indefinitely. Users see old prices, old opening hours, old availability, and no amount of refreshing fixes it because the service worker is answering before the network is consulted.
Version your caches and clean up old ones on activation. Decide deliberately which resources are safe to serve stale. Give yourself a way to force an update, and test the upgrade path rather than only the first install.
Never cache personal data on a shared device without considering who else uses it.
What it gains you
Repeat visits get faster, because the shell is already local. That is a real and measurable improvement.
The site becomes installable, which for a service people use regularly is a meaningful shift in how they reach you. No app store approval, no separate release process.
Basic functionality survives a poor connection, which matters more for some audiences than others. Field workers, rural users and anyone on public transport encounter this regularly.
And there is an efficiency argument. Cached assets are not re-downloaded on every visit, so returning users transfer less data. Where performance and environmental impact both apply, treat them as the same lever: reducing unnecessary transfer and processing supports a faster experience while lowering estimated digital carbon, though those figures remain modelled rather than directly measured.
When a PWA is the wrong answer
Be honest about the limits.
If you need deep platform integration, sophisticated background processing or hardware access beyond what the web platform exposes, native is still the right call. Capability varies between browsers and platforms, and it changes, so verify against current support rather than assuming.
If your site is a brochure people visit once before phoning you, installability solves a problem you do not have. The engineering effort would be better spent on the pages themselves.
And a PWA does not fix a slow site. It makes a fast site faster on return visits.
Accessibility still applies in full. Working towards WCAG 2.1 Level AA covers keyboard operation, focus management and clear error messaging, and an installed app has the same obligations as the site it came from.
The three things you are buying
- Installation. Your site can be added to a home screen and opened without browser chrome. This matters for services people reach several times a week and matters not at all for a site somebody visits once before phoning you.
- Offline capability. Cached content stays available when the connection drops. Valuable for field workers, rural users and commuters. Irrelevant if your audience is at a desk on fibre.
- Notifications. Support varies by platform and browser, and permission fatigue is real. Useful for genuine transactional updates, resented for marketing.
If none of those three describes a problem your business has, a PWA is engineering effort spent on capability nobody will use. That is the honest answer and it is not the one most agencies give.
Against a native app
Native still wins where you need deep platform integration, sophisticated background processing or hardware access beyond what browsers expose. Verify against current support rather than assuming, because the boundary moves.
A PWA wins on cost of ownership. One codebase instead of two or three. No app store review between you and a fix. No download barrier before someone can try the thing.
For most small and medium businesses the deciding factor is neither capability nor cost. It is whether anyone will actually install it. An app nobody keeps on their home screen is a website with extra steps, and the effort would have been better spent on the website.
The web.dev progressive web apps documentation sets out what the platform currently supports.
Our sustainable web development work covers both the underlying performance and the PWA layer.