PWA for Your Own Site: Offline Access, Install Prompts, Push Notifications, and Conversion
1. PWA’s Three Features: What Actually Works and What’s Just Hype
PWA rests on three core capabilities: Service Worker for offline caching, Web App Manifest for desktop installation, and Web Push API for push notifications. Sounds great, but the actual payoff on B2B sites is wildly uneven.
Offline caching (Service Worker) is the most valuable of the three. It pre-stores your site’s HTML, CSS, and JS on the user’s device, so the next visit opens instantly even offline or on a weak connection. For markets with unstable networks like the Middle East, Southeast Asia, and Latin America, LCP can drop from 4 seconds to under 2. To learn how to measure performance, see Core Web Vitals Optimization.
The value of the desktop install prompt (beforeinstallprompt API) varies by site. B2C ecommerce users may be willing to install a site on their desktop and use it like an app, but visitors to a B2B industrial site check a price and leave, so install rates typically sit between 2% and 5%. iOS Safari’s PWA support is especially limited: the install prompt never appears automatically, so you have to guide users to manually “Add to Home Screen.”
Push notifications are the most overrated. When a popup asks “Allow notifications?” on a user’s first visit, more than 80% click deny. Even among those who allow it, open rates typically stay below 5%. In B2B, customers would rather get an email than a browser push, so this capability contributes almost nothing to inquiry conversion.
| PWA Feature | How It Works | Real Impact on B2B Conversion | Development effort | Suggested priority |
|---|---|---|---|---|
| Offline caching | Service Worker precaching | LCP improves 30% to 50% in weak-network regions | 2 to 3 days | High |
| Desktop install | Manifest + beforeinstallprompt | 2% to 5% install rate, limited return-visit lift | 1 day | Medium |
| Push notifications | Web Push + server-side scheduling | Permission grant rate<20%，打开率<5% | 3 to 5 days | Low |
| Background sync | Background Sync API | Form submissions survive weak-network drops | 2 days | Medium |
| Home screen icon | Manifest icon + splash screen | Boosts brand feel, no direct conversion | Half a day | Medium |
2. When It’s Worth Doing and When to Skip It
Judge by three metrics: mobile traffic share, return visit frequency, and the network quality in your users’ region. Only when all three pass the bar is PWA worth the investment.
Scenario 1: An industrial valve site targeting the Middle East. Mobile accounts for 65% of traffic, users are mainly in Saudi Arabia and the UAE, 4G coverage is spotty, and the monthly return rate is 25%. Here the payoff from Service Worker offline caching is clear: a Saudi user checking product specs on a phone at a factory site gets instant loads even on a weak connection. A site like this is worth 2 to 3 days of Service Worker precaching. For how CDN fits in, see CDN global acceleration.
Scenario 2: A B2B equipment site targeting Europe and the US. Desktop accounts for 70% of traffic, users visit only 1.2 times on average, and the return rate is just 8%. Here PWA delivers almost nothing. Users come in, fill out an inquiry form, and leave. They will never install it on their desktop. Push notification opt-in rates are low and open rates are low, so it is pure wasted development. Spend those 2 weeks on form optimization and content instead, and you will get 10x the return. For how to analyze form abandonment, see Inquiry form abandonment rate.
| Decision Metrics | Not worth doing PWA | Consider offline caching | Worth full PWA |
|---|---|---|---|
| Mobile traffic share | Under 30% | 30% to 60% | Over 60% |
| Monthly return rate | Below 15% | 15% to 25% | Above 25% |
| Network in users’ region | Stable networks in Europe, the US, Japan, and Korea | Mixed regions | Weak networks in the Middle East, Southeast Asia, and Latin America |
| Average visits per user | 1 to 1.5 | 2 to 3 | More than 3 |
| Front-end team resources | 0 to 1 person | 1 to 2 people | More than 2 |
3. How to set up offline caching without making a mess of it
The most common Service Worker failure is “it cached an old version, so users keep seeing the old page.” That is not a PWA problem, it is a caching strategy that was not set up right. The correct approach is layered caching: use cache-first for static assets (CSS/JS/images) and network-first for HTML pages, trying the network every time and falling back to cache only on failure. That way users always see the latest content and only rely on cache when the network is down.
Another practical detail: Service Worker version updates. When you ship new front-end code, the old Service Worker is still controlling the cache on users’ devices. You need to write skipWaiting and clients.claim logic in the Service Worker, or prompt users on the page with “The site has been updated, click to refresh.” If you do not handle this, users may be stuck on the old version for a week.
A real-world example: A furniture site going global launched PWA and then found users complaining, “Why isn’t the site updating?” Investigation showed the Service Worker was also using cache-first for the homepage HTML. Marketing changed the homepage banner, but a week later users still saw the old image. Switching to network-first for HTML and cache-first for static assets solved the problem while keeping instant loads on subpages over weak networks.
| Asset type | Caching strategy | When to update | Common mistake |
|---|---|---|---|
| HTML pages | Network-first, fall back to cache on failure | Try the network on every request | Cache-first causes content not to update |
| CSS/JS (with hash) | Cache-first, long-term caching | Auto-updates when the filename hash changes | No hash, so old caches never expire |
| Images | Cache-first, refresh in the background | Pull the new version in the background and swap it in | Images are too large, so precaching fills up storage |
| API data | Network-first, cache as fallback | Try the network on every request | Cached prices, so users see outdated quotes |
| Font files | Cache-first, long-term caching | Update when the version changes | Cross-origin CORS not configured correctly |
4. Install prompts and push notifications: worth the effort?
If your site has already cleared the offline caching hurdle and you want to add an install prompt, listen for the beforeinstallprompt event, hide the browser’s default install prompt, and replace it with your own banner or button. When the user clicks the button, call prompt(). This gets 2 to 3 times more installs than letting the browser’s native prompt appear on its own, because the user clicks with some expectation of what happens next.
But in a B2B context, so what if install rates rise to 3% to 5%? Of those 3%, how many will actually come back more often because they installed the app? The data shows this usually adds less than 2% to return visits. The return on investment isn’t high.
Be even more careful with push notifications. Don’t ask “Allow notifications?” the first time a user visits; 80% will say no. The right moment is after the user completes a meaningful action, such as submitting an inquiry or downloading a whitepaper. Then ask, “Would you like updates on our pricing?” At that point, opt-in rates reach 30% to 40%. Even with permission, keep the frequency in check: no more than once a week, or users will immediately turn it off in their browser settings.
| Features | Native browser experience | After a custom prompt | Real B2B gains |
|---|---|---|---|
| When to show the install prompt | Shown on visit, 90% decline rate | Shown after engagement, 60% decline rate | Install rate up 1 to 3 percentage points |
| When to ask for push permission | Asked on first visit, 80% decline rate | Asked after a conversion action, 60% decline rate | Opt-in rate up 10 to 20 percentage points |
| Push open rate | Not applicable | 4% to 8% after optimization | Return visits up 1% to 3% |
| iOS Safari support | No automatic prompt | Users must be guided to add to home screen manually | Almost no gains on iOS |
FAQ
Does PWA help SEO?
How do you add a PWA to a WordPress site? Do you have to write the Service Worker yourself?
Do PWA push notifications work on iOS?
What if the Service Worker has cached an old version? How do I force an update?
How do I measure PWA install rate, and what counts as normal?
Will offline caching show users outdated prices and inventory?
Final thoughts
In the context of a B2B site, PWA is more of a nice-to-have optimization than a must-have. The only part really worth investing in is Service Worker offline caching, especially when weak-network markets like the Middle East, Southeast Asia and Latin America account for more than 30% of your traffic. Install prompts and push notifications bring very little return even when you build them, and skipping them won’t hurt your core business.
Start with the smallest viable step: install a PWA plugin, turn on offline caching only, and watch how LCP changes for returning mobile users over two weeks. If LCP in weak-network regions drops from 4 seconds to under 2.5 seconds, the investment is paying off. Hold off on install prompts and push notifications until you’ve confirmed offline caching works and your team has bandwidth to spare. Don’t try to ship all three PWA pieces at once.
One line worth remembering: the value of a PWA isn’t “installed on the home screen” — it’s “loads instantly even on a weak network.” The first is a gimmick; the second is the real problem.