Skip to content

What Is a PWA?

A Progressive Web App (PWA) is not a separate technology or a new kind of file you ship to an app store. It is a regular website that uses a specific set of modern web capabilities to behave like an installed, reliable, and fast native-feeling app — all from a URL.

That definition has three parts worth unpacking:

  • Installable — users can add it to their home screen or taskbar. The browser handles the install prompt; no app store review required.
  • Offline-capable — a service worker intercepts network requests and can serve cached responses when the device is offline or on a slow connection.
  • Fast — an app shell loads instantly from cache while dynamic content is fetched in the background, eliminating blank loading screens.

This course walks you from an empty folder to a fully audited PWA. Each section builds on the last:

  1. Introduction (this section) — what a PWA is, its history, and requirements.
  2. Web App Manifest — making your site installable and controlling how it appears on the home screen.
  3. Service Workers — the proxy thread that powers caching, offline, and background sync.
  4. Caching Strategies — choosing the right cache strategy for each resource type.
  5. Push Notifications — re-engaging users even when the browser is closed.
  6. Advanced APIs — Background Sync, Periodic Background Sync, and the File System Access API.
  7. Auditing & Deployment — running Lighthouse, fixing scores, and deploying over HTTPS.

Every PWA rests on four pillars. Remove any one and the app loses a core capability:

flowchart TD
  HTTPS["HTTPS\nSecure origin — required\nfor SW registration"]
  Manifest["Web App Manifest\nJSON file — controls install\nprompt and display mode"]
  SW["Service Worker\nBackground script — caching,\noffline, push, sync"]
  Shell["App Shell\nMinimal HTML/CSS/JS\nloaded from cache instantly"]

  HTTPS --> SW
  HTTPS --> Manifest
  Manifest --> Shell
  SW --> Shell
  Shell --> PWA["Progressive Web App"]
  Manifest --> PWA
  SW --> PWA
PWA building blocks

Service workers can intercept every network request a page makes. Browsers therefore refuse to register a service worker on a non-secure origin (anything other than https:// or localhost). HTTPS is not optional — it is the foundation everything else stands on.

A JSON file linked from your HTML that tells the browser your app’s name, icons, theme color, and how it should look when launched from the home screen. Without a valid manifest, browsers will not show the install prompt.

{
"name": "My PWA",
"short_name": "MyApp",
"start_url": "/",
"display": "standalone",
"background_color": "#ffffff",
"theme_color": "#5A0FC8",
"icons": [
{ "src": "/icon-192.png", "sizes": "192x192", "type": "image/png" },
{ "src": "/icon-512.png", "sizes": "512x512", "type": "image/png" }
]
}

A JavaScript file that runs in a background thread, separate from your page. It acts as a programmable network proxy — intercepting fetch requests, responding from cache, and enabling push notifications and background sync. Lessons in the Service Workers section cover this in depth.

The minimal HTML, CSS, and JavaScript needed to render the UI skeleton — headers, navigation, and layout — before any data loads. When the app shell is cached by the service worker, the skeleton appears instantly on repeat visits, even offline.

Which of the following best describes a Progressive Web App?
What are the three core properties that define a PWA?
What is the role of the app shell in a PWA?
Why is HTTPS a hard requirement for Progressive Web Apps?