Progressive Web App Fundamentals

Build the mental model

A Progressive Web App (PWA) is a regular website built with standard web technologies that also takes on capabilities that can make it feel more like an installed native application.

None of these capabilities are guaranteed everywhere, support varies by browser and operating system, so a PWA is better described as web app with some app-like upgrades where the platform allows it than as a fixed category with one guaranteed feature set.

• Installability onto a home screen or desktop
• Offline access to previously loaded content
• Control over caching behavior
• An app-like launch experience without browser chrome
• Background capabilities on platforms that support them
• Push notifications where the platform allows it

Two pieces of technology usually stand behind these capabilities. The Web App Manifest is a small metadata file describing the app: its name, icons, the URL it should open to, and how it should display itself when launched, such as filling the whole screen instead of showing browser tabs and address bars.

The Service Worker is a separate script the browser runs on behalf of the page, sitting between the browser and the network. It can intercept certain network requests as they happen, decide whether to serve a cached response or reach out to the network, and in some environments keep working on tasks in the background.

Offline-first is a deliberate design goal built on top of these pieces, not something that happens automatically just because a site technically qualifies as a PWA. It requires explicitly deciding what to cache, when to use that cache instead of the network, and how to handle the moment connectivity returns.

Progressive Web App

A website built with standard web technologies that can also take on app-like capabilities such as installability and offline support, where the platform supports them.

Service Worker

A script the browser runs on behalf of a page, sitting between the browser and the network, able to intercept requests and manage caching.

SERVICE WORKER AND OFFLINE-FIRST
--------------------------------
SERVICE WORKER AND OFFLINE-FIRST
------------------------------------
        [ Browser ]
             |
             v
      [ Service Worker ]
       /      |        \
      v       v         v
  [ Cache ] [ Network ] [ Background
                          tasks, where
                          supported ]

OFFLINE-FIRST DECISION FLOW
-------------------------------
   Request for data
         |
         v
   Network available?
      /         \
    Yes          No
     |            |
     v            v
 Use network   Use cached content
  response      (if available)

Connect it to a real scenario

Deciding whether a project is worth building as a PWA starts with a concrete question: would users genuinely benefit from installing this and opening it like an app, or from having it keep working with spotty connectivity?

A note-taking app used on a commute through subway tunnels benefits enormously from offline support and an installable icon. A one-page calculator that is opened once and rarely revisited gains little from either.

Once a team decides a PWA approach fits, the offline-first behavior still has to be designed deliberately, page by page and resource by resource. A news app might cache article text so it reads offline but intentionally skip caching live comment counts, since stale comment counts could mislead a reader more than showing nothing at all.

It also helps to compare against a native app honestly rather than assuming a PWA is simply a lighter native app. A PWA usually distributes through a normal web link instead of an app store, generally reaches multiple platforms from one codebase, and can skip store review delays, but it also has narrower access to certain device hardware and background capabilities that a fully native app can reach more directly on some platforms.

• A PWA is a website with optional app-like capabilities like installability and offline support, not a guaranteed fixed feature set.
• The Web App Manifest describes the app, while the Service Worker intercepts network requests and manages caching.
• Offline-first requires deliberate design decisions about what to cache and when, it does not happen automatically.

Try the working example

function handleFetch(requestPath, { cache, isOnline }) {
  if (isOnline) {
    // Network-first: a real service worker might also refresh the cache here.
    return { requestPath, source: "network", data: `LIVE:${requestPath}` };
  }
  if (cache[requestPath]) {
    return { requestPath, source: "cache", data: cache[requestPath] };
  }
  return { requestPath, source: "unavailable", data: null };
}

const cache = {
  "/index.html": "cached homepage markup",
  "/style.css": "cached stylesheet",
};

console.log(handleFetch("/index.html", { cache, isOnline: true }));
console.log(handleFetch("/index.html", { cache, isOnline: false }));
console.log(handleFetch("/new-page.html", { cache, isOnline: false }));

For an online request to /index.html, it returns { source: 'network', data: 'LIVE:/index.html' }. For the same path offline, it returns { source: 'cache', data: 'cached homepage markup' }. For an uncached path while offline, it returns { source: 'unavailable', data: null }.

MDN — Progressive web apps (PWAs) — How the Web Works