Progressive Web Apps (PWAs) : Understand in 3 Minutes

Problem Statement

A Progressive Web App (PWA) is a website that behaves like a native mobile app — it loads instantly, works offline, and can send push notifications — without requiring users to visit an app store. You’ve probably shipped a web app only to hear “it feels sluggish” or “why can’t I use it without internet?” Meanwhile, your product lead wants the engagement of a native app but can’t justify two separate codebases. PWAs bridge that gap, giving you app-like experiences from a single web codebase, but only if you know when and how to use them.

Core Explanation

A PWA is a website enhanced with three core technologies that together unlock native-like capabilities. Think of it like a Swiss Army knife: your regular website is the blade (content and logic), and the PWA features are the extra tools (offline, push, home screen) that fold out when needed.

Here’s what makes a PWA work:

Service Worker – A JavaScript file that runs in the background, separate from your web page. It intercepts network requests and acts as a smart cache. When the user has connectivity, it updates cached resources. When offline, it serves the last-known-good version of your app. This is the engine behind offline support and fast loading.
Web App Manifest – A JSON file that tells the browser how your app should look when installed on the home screen. It defines the icon, splash screen, theme color, and display mode (e.g., full-screen). Without this, the user can’t “install” your PWA.
HTTPS – Service workers only run on secure origins (HTTPS). This ensures that the code intercepting network traffic hasn’t been tampered with. Non-negotiable.

The magic happens when a user first visits your site. The browser silently installs the service worker. On subsequent visits, the service worker serves cached assets, making load times near-instant (even on flaky networks). If the user taps “Add to Home Screen,” the manifest kicks in, and your app appears in their app drawer — no store required.

Analogy: A PWA is like a library book you photocopy. The original (server) might be far away, but you keep a copy in your backpack (cache). You can read it anywhere, even in a tunnel. When you get back to WiFi, you update your copy with new pages (background sync).

Practical Context

Use PWAs when:

You need offline or poor-network capability (e.g., a news reader, a field-service checklist, a travel guide).
You want to reduce friction to re-engage users (push notifications + home screen install = higher retention).
You’re building a content-driven or lightweight app and want to skip the app store approval process.
You have a web app already and want to improve performance — adding a service worker can be incremental.

Don’t use PWAs when:

Your app requires deep device hardware access (Bluetooth, NFC, camera in background) — PWAs still can’t do everything native apps can (though APIs are expanding).
You need sophisticated background processing (e.g., a fitness tracker recording GPS continuously) — service workers have limited background execution time.
Your audience heavily relies on iOS — Safari’s PWA support has historically lagged (push notifications only arrived in iOS 16.4, and some features still differ). For enterprise/B2B apps on Android, PWAs are a no-brainer.

Common use cases:

E-commerce – Pinterest’s PWA saw a 60% increase in core engagement and 44% increase in user-generated ad revenue.
News/Media – The Washington Post’s PWA reduced load time from 4 seconds to <1 second.
Travel/Offline-first – Trivago’s PWA achieved a 150% increase in user engagement by providing offline hotel search.

Why you should care: PWAs can boost conversion rates, reduce bounce rates (because pages load fast), and shrink your development and maintenance costs. If your metric is “user action” (click, purchase, read), a PWA often outperforms both a slow website and a minimal native app.

Quick Example

Here’s the minimal code to register a service worker — the first step to making any site a PWA:

// In your main script (e.g., app.js)
if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/sw.js')
    .then(reg => console.log('SW registered', reg))
    .catch(err => console.log('SW failed', err));
}

And the corresponding sw.js (service worker) for offline fallback:

self.addEventListener('fetch', event => {
  event.respondWith(
    fetch(event.request).catch(() => {
      return caches.match('/offline.html');
    })
  );
});

What it demonstrates: The first script checks if the browser supports service workers (modern browsers do), then registers the file sw.js. The sw.js intercepts every network request. If the fetch fails (user is offline), it serves a cached offline.html page instead of showing a browser error. That’s the core of offline resilience — about 10 lines of code.

Key Takeaway

A PWA is not a framework or a rewrite; it’s a progressive enhancement you add to your existing website using a service worker and a manifest. You can ship offline support and “installability” incrementally, starting with just a few lines of JavaScript. If you want to dive deeper, read the MDN guide on service workers — it covers caching strategies and lifecycle.

推荐订阅源