PortfolioBlogAboutContact
Hero image

PWAs: The 80% of Value Nobody Talks About

Published: May 03, 2024

Every article about Progressive Web Apps reads the same. Faster load times. Offline access. Push notifications. Install to home screen. Boost engagement by 2–5x. Revenue goes up.

I've been shipping PWAs for clients for years — e-commerce stores, SaaS dashboards, internal tools, content platforms. After that many projects, the patterns are clear. Some of the promises delivered. Most of them didn't. And the features that actually moved the needle are not the ones you'll find in the headline of a typical PWA article.

Most PWA content online is written by people who've never built one. They're rewriting the same Google case studies from 2018. This post is what I'd actually tell a client who asks "should we build a PWA?" — based on what I've seen repeat across many projects, not one cherry-picked success story.

The short answer: yes, but probably not for the reasons you think.

What a PWA Actually Is

Strip away the marketing and a PWA is a website that registers a service worker and ships a manifest.json. That's the entire technical bar.

The service worker is a script that runs in the background and intercepts network requests — this is what enables caching strategies, offline fallbacks, and faster repeat loads. The manifest is a JSON file that tells the browser how to handle "Add to Home Screen" — app name, icon, theme color, display mode.

Everything else — push notifications, background sync, app-like transitions — is optional. And the support for those optional features varies wildly by browser and platform.

If you're on Next.js (which is where most of my client work lives), adding PWA support is a configuration layer, not a rebuild. Tools like Serwist (the successor to the now-deprecated next-pwa) handle the service worker registration and caching setup. You're not adopting a new tech stack. You're adding a config file and a build plugin.

That distinction matters because it changes the cost/benefit calculation entirely.

The Features That Actually Delivered

Caching and Speed — The Real Win

This is the 80% of PWA value that nobody writes clickbait about.

Service worker caching strategies — stale-while-revalidate for API responses, cache-first for static assets, network-first for dynamic content — make returning visits near-instant. The browser serves cached resources while fetching fresh ones in the background. The user sees the page immediately.

Across client projects, the pattern is consistent. On one e-commerce site, implementing service worker caching dropped repeat-visit load time from roughly 2.5 seconds to under 400 milliseconds. That's not some exotic PWA capability — it's smart HTTP caching with a programmable layer. But the PWA framework gives you the structure and the API to do it properly, consistently, across every route.

The downstream effects are real: Lighthouse performance scores climb, which maps directly to Core Web Vitals, which maps to search ranking. On sites where I've added service worker caching, the Lighthouse performance score typically jumped 10–20 points on repeat visits. That's a measurable SEO input.

This is the one feature I'd recommend to every client, regardless of whether they care about anything else on the PWA checklist. The cost is low (a Serwist config and a manifest.json), the benefit is immediate, and it compounds over every returning user.

Add to Home Screen — Situational

This is the feature people picture when they hear "PWA." The user taps an install prompt, the site appears on their home screen like a native app, and it launches in a standalone window without the browser chrome.

In practice, it works well for a narrow set of use cases: internal tools, dashboards, and niche e-commerce with loyal repeat customers — sites where users visit daily or weekly and benefit from fast, focused access.

It doesn't move the needle for content sites, blogs, marketing pages, or anything where users arrive via search and leave after one session. There's no install behavior to capture because there's no repeat-visit pattern.

The install prompt UX is also awkward. It varies by browser, it's not customizable without extra work, and most users don't intuitively understand what "installing a website" means. You can build a custom install UI to improve this, but it's additional development for a feature with low adoption.

Across the client sites I've built PWAs for, fewer than 2% of users installed to home screen. For the ones that did, session duration and return rates were significantly higher. But 2% of your traffic is a niche within a niche — meaningful for the right product, irrelevant for most.

The Features That Underdelivered

Offline Access — Almost Nobody Uses It

The pitch sounds compelling: "Users can browse your site without internet!" The question I always come back to: when was the last time you opened a website while offline on purpose?

Across every client site I've tracked over the years, offline page views accounted for less than 0.5% of total traffic. The custom offline fallback page — you know, the one you spend time designing with a friendly "you're offline" message — is seen almost exclusively by developers testing it during QA.

The exception is real but narrow: field-work applications where connectivity is genuinely unreliable. Construction management tools, medical data entry in rural clinics, delivery driver apps. If your users are regularly in areas without signal, offline support matters. For a standard website, an e-commerce store, or a SaaS dashboard used on stable WiFi, it's a checkbox feature.

My recommendation: implement a basic offline fallback. It's roughly 20 lines of service worker code and it prevents users from seeing an ugly browser error page. But don't let anyone sell you a three-sprint project around offline capability for a site that's used on broadband.

Push Notifications — The Spam Problem

Web push notifications have a permission-grant rate of roughly 5–10% according to PushEngage's industry benchmarks. That's the ceiling — the percentage of users who even agree to receive them. Of those, most tune them out or actively block them within weeks.

The problem isn't the technology. It's the reputation. Years of spammy "Allow notifications?" prompts on every site trained users to click "Block" reflexively. The permission prompt itself has become a signal to leave.

On one client site, we implemented push notifications for new product alerts. Open rates started at around 12% and decayed to under 3% within two months. We eventually turned the feature off. The brand damage from annoying people outweighed the marginal conversions it drove.

Compare this to email: higher open rates, better segmentation, user-controlled frequency, works across every device, and no browser permission dialog. For most businesses, email still wins as a re-engagement channel. Push notifications are a worse version of email with a worse user experience around consent.

The Apple Problem

This section deserves its own heading because it's the single biggest factor that most PWA articles conveniently skip.

Safari on iOS deliberately limits PWA capabilities. Push notifications weren't supported until 2023 — years behind Chrome and Firefox. Background sync still doesn't work. Service worker lifetime is aggressively limited. Web apps added to the home screen run in a sandboxed WebKit instance with restrictions that don't apply to native apps from the App Store.

In early 2024, Apple went further: they threatened to remove PWA home screen support entirely in the EU as a response to the Digital Markets Act, before reversing course after backlash from developers and the Open Web Advocacy group. The reversal was welcome, but the threat itself tells you exactly where PWAs sit in Apple's strategic priorities: they're tolerated, not supported.

If your audience is 50%+ iOS — and most B2C sites are — you're building a PWA where half your users will experience it as a slightly-faster-than-normal website with none of the app-like features. No home screen presence. No real push. No background updates.

This isn't a technical problem you can engineer around. It's a platform politics problem. Any honest PWA recommendation has to address it head-on.

When I Recommend a PWA (And When I Don't)

After years of building these, here's the decision framework I actually use:

Build the PWA when:

  • Users visit repeatedly and speed matters — dashboards, SaaS tools, internal apps, niche e-commerce with loyal customers
  • You're already on Next.js or a modern framework — adding Serwist is a configuration change, not a rebuild. The cost is low, the caching benefit is real.
  • You want Lighthouse and Core Web Vitals improvements — the PWA requirements (HTTPS, service worker, manifest) force good performance hygiene as a side effect
  • Your audience includes emerging markets where low-end devices and slow mobile connections are common — aggressive caching genuinely changes the experience

Skip it when:

  • The real problem is performance — a PWA on top of a slow, bloated codebase is still a slow site with a service worker attached to it. Fix your bundle size and rendering strategy first.
  • The client actually needs a native app — if the requirements include camera access, Bluetooth, background location, or rich notification management, a PWA is the wrong tool. Overselling it wastes money and delays the real solution.
  • Someone pitched "it'll replace our native app" — it won't. The capability gap is real, especially on iOS. User experience is not as smooth as native app, some integrations are limited, especially if you are working under a corporate rules. I've seen this promise burn clients who then need to build the native app anyway.

What I Actually Ship on Client Next.js Sites

When a client project fits the "build it" criteria, here's the minimum viable PWA I add. Not the feature-complete dream from a Google I/O talk — the version that delivers the real value without the bloat.

The stack:

  • Serwist for service worker generation and caching configuration
  • A manifest.json with proper icons, theme color, and display: "standalone"
  • A caching strategy config: cache-first for static assets (JS, CSS, images), stale-while-revalidate for API data, network-first for HTML pages
  • A basic offline fallback page (one component, 20 lines)
  • Push notification setup (ther must be a clear, specific use case with a re-engagement strategy behind it)

What I skip:

  • Complex offline data sync (unless it's a field-work tool)
  • Custom install prompt UI (only the UI for update)

That's it. The full implementation is usually a few hours of configuration, not a multi-week project. The caching alone justifies the time on every site that has returning users.

Conclusion

PWAs are a useful tool, not a revolution. The caching and performance layer is genuinely valuable — I add it to almost every Next.js project I ship. Everything else is situational, and most of the situational features underdeliver for the average website.

The honest answer to "should I build a PWA?" is almost always: add service worker caching to your existing site and skip the rest unless you have a specific, evidence-based reason to include it.

The worst PWA outcome I've seen isn't a failed implementation. It's a client spending months of budget on offline support and push notification infrastructure that nobody ends up using — because someone pitched the full feature set instead of the part that actually works.

I wrote a more optimistic take on PWAs a while back, before the pattern became this clear. Consider this the update.

Architecture decisions like this — what to build, what to skip, where the real ROI lives — are what we talk about in The Agentic Architect Lab. It's a community of senior devs shipping faster with AI, making real trade-offs on real projects, no hype. If that sounds like your kind of conversation, come join us.

Sources

← Prev PostNext Post →