Progressive Web Apps: The Web Learns App Tricks Without the App Store

Google spent a striking share of its I/O keynote this month on an idea with an awkward name and a serious premise. Progressive Web Apps: ordinary websites that, by adopting a short list of modern capabilities, take on the properties users value in native apps. Working offline. Loading instantly on repeat visits. Sending notifications. Living on the home screen. All while keeping the properties organizations value in the web: one codebase, every platform, no store gatekeeping, a URL anyone can reach.

The capability doing the heavy lifting is the service worker. A script the browser installs on first visit that sits between your site and the network. It can cache intelligently, serve from cache when the network fails or dawdles, and receive push messages when the site is closed.

Add HTTPS, which is required and one more compounding return on the migration we have urged for years. Add a manifest file describing the home-screen presence. The PWA checklist is then largely complete.

The demos are compelling, the early case studies are circulating, and the client questions have started. The sorted answer: One durable core worth adopting broadly. One powerful capability worth adopting carefully. One boundary worth stating plainly, and an economics reset worth taking seriously.

The durable core: service workers for everyone

Strip the branding and the lasting value is the service worker itself, and it applies to ordinary sites with no app-like ambitions at all.

A service worker caching your site’s shell and key assets makes repeat visits load in the near-instant territory the AMP coverage showed behavior follows. It makes flaky-network experiences, the cellular reality our mobile coverage centers, degrade gracefully instead of failing blankly. And it gives performance budgets a powerful new instrument.

Conservative service workers (asset caching, offline fallback pages) are the sensible start, and the public case studies agree on the payoff: repeat-visit speed transforms.

The cost is a genuinely new discipline the implementation notes must respect, because a service worker is a cache you have shipped into your visitors’ browsers. Cache-invalidation carelessness now strands stale sites on other people’s devices. Versioning discipline, conservative scopes, and staged rollouts are the craft. The tooling and patterns emerging from this year’s push make them learnable in a sprint.

Progressive enhancement, the approach argued here since 2006, is the architecture by name and by design. The site works everywhere. The enhancement layers where the browser affords it.

The careful capability, the boundary, and the economics

• Push notifications: engagement power priced in trust. Web push is real and arriving, and its economics are the permission prompt’s. Asked at the wrong moment, the on-arrival prompt already spreading across the web, the request reads as presumption and the denial is durable. Asked in context, after value is established, for a purpose the user actually wants, it is a genuine channel. The application-status update, the closure alert, the order notice. Our advice mirrors the email rules of a decade ago, because it is the same rule. Permission is an asset built by respect. The institutions that spend the prompt carelessly will find, as the careless emailers did, that the channel closes from the user’s side. Prompt late, prompt specific, measure honestly.

• The boundary: Safari. Apple has shipped none of this and signaled little. The iOS share of your audience (check your January numbers, since for most institutional audiences it is the largest single slice) experiences your PWA as a website, full stop. That bounds the near-term case. Build service workers for the universal performance win. Treat the app-like layer as an Android-and-desktop enhancement. Let the standing progressive-enhancement architecture absorb the asymmetry the way it absorbs every browser gap. The boundary is Apple’s to move, and the strategic pressure of the PWA push is partly aimed at moving it.

• The economics reset: the app question, reopened. For the institutions that have been pitched native apps ‘because mobile,’ most of our readership, repeatedly, PWAs reset the arithmetic. The content-and-service experiences that make up most institutional app proposals (news, directories, schedules, forms) are precisely what a PWA delivers at web cost with web reach. No store, no install cliff, no dual-platform build. The native case narrows to what genuinely needs device depth. Bring this post to the next app pitch. The correct first question is now ‘why can’t this be a PWA?’, and the real answers are rarer than the pitches.

A first sprint, sketched

For the teams ready to move, the conservative recipe our first deployments have settled into, sized to a sprint.

Prerequisite check: HTTPS site-wide, because nothing else starts without it.

Scope: a service worker that precaches the site shell and core assets, applies a cache-first strategy to static resources and network-first to content, and serves a designed offline fallback page. Branded, useful, with the phone number. Not the browser’s dinosaur.

Explicitly out of scope for the first pass: push notifications, background sync, and any caching of logged-in or personalized responses. Each of those earns its own sprint with its own review.

The discipline items that make it safe. A versioned cache name and activation cleanup, so updates actually update. A kill-switch deployment path rehearsed before launch. The stranded-stale-site failure mode is recoverable if you have practiced the recovery, and miserable if you have not. Scope limited to the paths you have reasoned about. And the measurement plan wired before shipping: repeat-visit timing, offline pageview counts, and the performance budget’s numbers re-baselined after.

Ship it to a section before the site, per the pilot rule, and let a month of field data make the site-wide case. Every team we have run this recipe with has ended the sprint asking what else the worker can do, which is the correct appetite in the correct order.

Reading the keynote as strategy

I/O keynotes are strategy documents read properly. Google is arming the open web for its competition with the app stores and the walled feeds, and PWAs join AMP in the campaign. The same reading discipline applies: adopt what serves your users on your terms, and price what serves the platform’s campaign.

Service workers pass that reading easily. Capability, standards-track, progressive, yours. The app-like layer passes conditionally. Real value, trust economics, one large boundary.

And the awkward name will fade the way names do, while the capabilities become, per the usual absorption pattern, simply how good sites work. Our deployment queue says that has already started. The next capacity-planning piece will assume a service worker the way this year’s assumed a CDN, and the sites that adopted early will, as usual, experience the transition as nothing at all.