How to build a PWA (progressive web app): a practical guide

How to build a PWA, in brief: serve your site over HTTPS, add a web app manifest so it can be installed to a home screen, and register a service worker so it keeps working offline. Those three additions turn any existing website into an installable, reliable progressive web app. This guide walks through each step in a framework-neutral way, so the same process applies whether you use React, Vue, Angular, or plain JavaScript.

By Kanika Mathur, Head of Service Delivery

Reviewed by Resourcifi engineeringPublished Feb 21, 2026Updated Feb 21, 202610 min read

Web

Key takeaways

The short version

A PWA is a website plus three additions: HTTPS, a web app manifest, and a service worker. You do not rebuild your app, you progressively enhance it.
The manifest makes it installable. Chromium browsers need a name, a 192px and a 512px icon, a start_url, and a display value before they offer an install prompt.
The service worker makes it reliable. It sits between the page and the network, caches files, and serves them when the connection drops.
Service workers are no longer required for installability, but you still want one for any real offline experience, per MDN.
It is framework-agnostic. The manifest and service worker work the same in React, Vue, Angular, or vanilla JavaScript; tooling just generates them for you.

What a progressive web app actually is

A progressive web app is a regular website that uses modern browser features to behave like an installed app. Technically it is the combination of three things: the site is served over HTTPS, it ships a web app manifest that lets the browser add it to a home screen, and it registers a service worker that can cache assets and respond when the network is unavailable. Nothing about it is tied to a specific framework. You build the site as you normally would, then add the manifest and service worker on top.

The model is called progressive enhancement for a reason: the app works as a plain website everywhere, and the extra capabilities switch on in browsers that support them. Adoption is climbing as a result. Per the HTTP Archive Web Almanac, roughly one fifth of sites now register a service worker, about a ten times increase since 2022. If you want the broader build decision first, see our guides on how to build an app and native vs hybrid vs cross-platform.

How to build a PWA, step by step

Building a PWA comes down to four steps. First, serve your site over HTTPS, because installability and service workers only work in a secure context. Second, add a web app manifest, a small JSON file listing the app name, icons, start URL, and how it should display. Third, register a service worker and use it to cache your core files so the app loads offline. Fourth, test installability and offline behavior with a tool like Lighthouse. Each step is independent, so you can ship them one at a time.

Serve over HTTPS. Use a real certificate in production, or localhost during development, which browsers treat as secure.
Add the manifest. Create a JSON file with name, icons, start_url, and display, then link it from your HTML with a manifest link tag.
Register a service worker. Feature-detect support, register the script, and cache your shell files on the install event so they are available offline.
Choose a caching strategy. Cache-first suits static assets, network-first suits fresh content, and stale-while-revalidate balances both.
Test and audit. Run Lighthouse to confirm the manifest is valid, the service worker is registered, and the app meets installability requirements.

The service worker has three core lifecycle events you will work with: install, where you populate the cache; activate, where you clean up old caches; and fetch, where you intercept requests and decide whether to serve from cache or network, as MDN documents. In the field most service workers handle the activate event and a large share handle install, while advanced features like push notifications and background sync stay relatively rare, according to the HTTP Archive.

PWA capabilities checklist

A production PWA is more than a manifest and a service worker. Use the checklist below as a reference for what each capability does, what it needs, and whether it is required. The non-negotiables are HTTPS, a valid manifest with the right icons, and a registered service worker for offline support. The rest are enhancements you add based on what your app needs, such as push notifications or background sync.

PWA capabilities checklist
Capability	What it does	Needs	Required
HTTPS	Secure context for install and APIs	TLS certificate, or localhost	Yes
Web app manifest	Lets the OS install the app	name, icons, start_url, display	Yes
Icons	Home screen and launcher art	192px and 512px, plus maskable	Yes
Service worker	Caching and offline support	Registered script, secure context	For offline
Offline page	Graceful fallback with no network	Cached shell or fallback route	Recommended
Push notifications	Re-engage users off-page	Push API, user permission	Optional
Background sync	Retry actions when back online	Background Sync API	Optional

For the manifest, MDN states that Chromium browsers require a name or short_name, an icons array containing a 192px and a 512px icon, a start_url, and a display value before they will offer an install prompt. web.dev adds that if you ship only one icon it should be 512 by 512 pixels, and that maskable icons keep important detail inside a safe zone so adaptive launchers do not crop your art.

~19%

Share of sites registering a service worker, about ten times higher than 2022.

HTTP Archive Web Almanac

78%

Of manifests use the standalone display mode for an app-like window.

HTTP Archive Web Almanac

192 + 512

The two icon sizes Chromium browsers require for an installable PWA.

MDN Web Docs

PWA vs native app: when to choose which

Choose a PWA when reach, instant access, and a single codebase matter most, and choose a native app when you need deep device integration, the highest performance, or app store distribution. A PWA installs from the browser with no store review, updates instantly, and runs from one codebase across platforms, which lowers cost and time to market. A native app gives you full access to platform APIs, the smoothest graphics, and a presence in the app stores, at the cost of separate builds and store processes. Many teams start with a PWA to validate the product, then add native apps where the platform features justify them.

PWA vs native app at a glance
Factor	PWA	Native app
Distribution	From a URL, no store review	App stores, with review
Codebase	One, runs everywhere	Often one per platform
Updates	Instant on next load	Through store releases
Device APIs	Growing, some gaps	Full platform access
Performance	Good for most apps	Best for heavy graphics
Discovery	Search and links	Store listings

The choice is rarely all or nothing. If you are weighing platforms in detail, our web development and mobile app development teams help map the right approach to your roadmap and budget.

Frequently asked

PWA build questions

What do you need to build a PWA?

You need three things on top of a normal website. First, your site must be served over HTTPS, or localhost during development, because installability and service workers only run in a secure context. Second, you add a web app manifest, a small JSON file that lists the app name, icons, start URL, and display mode. Third, you register a service worker to cache files and handle offline. None of this is tied to a framework, so the same steps work in React, Vue, Angular, or plain JavaScript.

What is a web app manifest and what does it need?

A web app manifest is a JSON file that tells the operating system how to install and display your app. According to MDN, Chromium browsers need a name or short name, an icons array containing both a 192px and a 512px icon, a start URL, and a display value before they offer an install prompt. You link it from your HTML with a manifest link tag. web.dev recommends adding a maskable icon so adaptive launchers do not crop the corners of your artwork.

Is a service worker required for a PWA?

Not for installability anymore. MDN notes that modern Chromium browsers offer the install prompt based on a valid manifest and a secure context, so a service worker is no longer a strict requirement to install. You still want one for any real PWA, though, because the service worker is what caches your files and lets the app load when the network is slow or unavailable. Without it the installed app simply will not work offline.

What does a service worker do?

A service worker is a script the browser runs in the background, separate from your page, that sits between the app and the network. MDN describes three core lifecycle events. On install you populate a cache with your core files. On activate you clean up old caches from previous versions. On fetch you intercept network requests and decide whether to serve from cache or go to the network. This is what enables offline support, and it can also power push notifications and background sync.

Can you build a PWA with React or any framework?

Yes. A PWA is framework-agnostic because the manifest and service worker are web platform features, not framework features. You can add them to a React, Vue, Angular, Svelte, or plain JavaScript project, and most build tools can generate the manifest and a service worker for you. The browser only cares that a valid manifest is linked and a service worker is registered. Your framework choice affects how you write the app, not whether it can become a PWA.

PWA vs native app, which should you choose?

Choose a PWA when reach, instant updates, and a single codebase matter most, since it installs from a URL with no store review and runs everywhere from one codebase. Choose a native app when you need deep device integration, the highest graphics performance, or a presence in the app stores. The trade-off is that native apps usually mean separate builds and store processes. Many teams ship a PWA first to validate the idea, then add native apps where platform features justify the extra cost.

Kanika Mathur

Head of Service Delivery, Resourcifi

I am Kanika Mathur, Head of Service Delivery at Resourcifi. We build PWAs as progressive enhancements on top of solid websites, so clients get installable, offline-capable apps without locking into one framework. This guide reflects the same checklist our engineers use on client projects, refined across the products we have shipped since 2017.

Resourcifi on LinkedIn →

Sources

MDN Web Docs, Making PWAs installable (installability requirements, HTTPS, service workers).
web.dev, Web app manifest (manifest fields, icon sizes, maskable icons).
MDN Web Docs, Service workers tutorial (lifecycle events, Cache API, offline).
HTTP Archive, Web Almanac PWA chapter (adoption, display modes, icon sizes).