How to turn your website into a progressive web app step by step

A website that behaves like an app, loads instantly, works offline, and can sit on a user's home screen, without going near an app store. That is the promise of a Progressive Web App, and it is a genuine one. The technical path from a standard website to a PWA is well documented. The part that gets skipped is what happens to the experience when you get there, and whether your site was ready to make that journey in the first place.

We work on digital products for lifestyle brands, and the PWA question comes up often. Usually framed as a technical decision. Should we build a native app or go PWA? Can we retrofit offline support onto what we already have? The answer to the second question, particularly, is almost always more complicated than the person asking it expects.

Step 1: Audit Your Existing Site

Before adding anything, understand what you have. Open Chrome DevTools and run a Lighthouse audit. It will score your site across performance, accessibility, best practices, and PWA readiness, and it will tell you exactly what is missing. Pay attention to the performance score first. A PWA that loads from cache instantly but has a core web experience that is slow and cluttered has not solved the right problem.

Look at every page your users are likely to visit as part of a typical session. Note which assets are large, which requests are slow, and which third-party scripts are adding load time without adding value. Note where the site breaks on a slow mobile connection, because those are the moments your offline strategy will need to address.

Also audit the experience itself, not just the performance. Question every piece of information on each screen. Consider the context in which someone will use this page, their emotional state, their likely intent, whether each element earns its presence or just adds noise. A PWA conversion is a natural point to tighten the experience, and an audit that only checks the technical boxes misses that opportunity.

Run your Lighthouse audit three times and average the scores. A single run can be skewed by background processes or network variation, and decisions made on one reading can lead you in the wrong direction.

Document what you find. The audit report becomes the brief for everything that follows, and having a clear baseline makes it possible to measure what the conversion actually changed.

Step 2: Switch to HTTPS

HTTPS is not optional for a PWA. Service workers will not run on HTTP, and browsers will not prompt users to install a PWA from an unencrypted connection. If your site is still on HTTP, switching to HTTPS is the first concrete step.

For most sites on modern hosting, this is straightforward. Let's Encrypt provides free SSL certificates, and most hosting platforms can install and renew them automatically. Platforms like Netlify, Vercel, and Cloudflare handle HTTPS with effectively no configuration. If your site is on shared hosting or a legacy server, the process takes a little more work but is still well within reach of a competent developer.

Once HTTPS is live, update all internal links and asset references to use HTTPS rather than HTTP. Mixed content, a page served over HTTPS that loads images or scripts over HTTP, will cause browsers to block those assets or throw security warnings. A redirect rule that forces all HTTP traffic to HTTPS is the clean way to handle this.

Test every page after the switch. Check that forms still submit correctly, that payment flows still work, and that third-party embeds have not broken. Most do not, but some older third-party scripts do not support HTTPS and will need replacing.

Use the browser's security panel in DevTools to check for mixed content warnings after switching to HTTPS. A green padlock in the address bar is a start, but the panel will catch asset-level issues the padlock does not show.

Step 3: Create Your Web App Manifest

The web app manifest is a JSON file that tells the browser how your app should appear and behave when installed. It controls the name that appears on the home screen, the icons used at different sizes, the colour of the browser chrome when the app is open, the orientation it launches in, and whether it opens with browser navigation visible or in a full-screen standalone mode.

A minimal manifest looks like this, as a description rather than code: it declares a short name for the home screen, a full name for the splash screen, a start URL, a display mode (standalone removes the browser address bar), a background colour, a theme colour, and an array of icon sizes ranging from 192px to 512px.

Icon quality matters more than it might seem. The icons appear on home screens, in app switchers, and on splash screens. A blurry or poorly cropped icon signals to users that the experience is not fully considered, and first impressions at the icon level carry over into how users perceive the product overall.

Once the manifest file is created, link it in the head of every HTML page with a link tag pointing to the file. The browser will not find it unless it is explicitly referenced. Test that it is being read correctly by checking the "Manifest" panel in Chrome DevTools under the Application tab.

Step 4: Build and Register a Service Worker

The service worker is a JavaScript file that runs in the background, separate from your main page. It acts as a proxy between your app and the network, intercepting requests, serving cached responses, and handling what happens when the network is unavailable. It is what makes a PWA feel reliable rather than just fast.

Service workers follow a lifecycle: they are registered, then installed, then activated. During installation, they typically cache a set of assets. During activation, they clean up old caches. After activation, they intercept fetch requests and decide how to respond, from cache, from the network, or from a fallback.

Registration happens in your main JavaScript file. You check whether the browser supports service workers (not all do, though coverage is now very broad), and if it does, you register the service worker file. The service worker itself lives at the root of your site, because its scope, the pages it can control, is determined by where the file sits.

If your site uses a framework, check whether PWA tooling already exists for it. Workbox, from Google, provides a library that handles most common service worker patterns without requiring you to write the lower-level logic from scratch. Next.js has next-pwa, Nuxt has a dedicated PWA module. These are worth using. Writing a service worker from scratch introduces opportunities for bugs that are particularly hard to debug.

Step 5: Decide What to Cache, and What Not To

This is where PWA work gets genuinely interesting, and where most technical guides stay at the surface level. Caching everything is not the answer. Caching the wrong things creates a worse experience than caching nothing.

The framework we use when advising on cache strategy starts with the user journey. Identify the highest-stress moments, the points where connectivity failure would be most damaging. For the travel app we worked on, those moments were ticket retrieval, itinerary access, and map navigation in remote locations. Those needed to work regardless of signal. A booking amendment or a payment, on the other hand, requires a server round trip and should fail gracefully with a clear message rather than silently queue a request the user does not know about.

Apply a dependency test to each feature: does it need a server response, or can cached data serve it fully? How often does that data change? Passive content, saved items, reference material, maps, is a strong candidate for offline-first caching. Transactional content is not.

Step 6: Design Your Offline Experience

An offline experience is a designed state that users encounter when the network is unavailable, and how that state is handled shapes how the product feels overall. A bare "you're offline" screen in a branded wellness app is a failure of the same kind as a mismatched font, it breaks the coherence of the experience at exactly the moment the user needs reassurance.

The offline page should feel like it belongs to the product. It should tell the user clearly what is unavailable, what they can still do, and, where relevant, that their data is safe and will sync when connectivity returns. Think of the product as a person. What would that person say to you if something was temporarily out of reach? Probably something calm, direct, and reassuring, not a raw browser error string.

For most lifestyle brands, the offline state is relatively rare. But for products that go where connectivity is unreliable, a hiking app, a travel companion, a festival wristband product, the offline state is a core part of the experience. For the travel app we worked on, the absence of a designed offline state was described as an absolute disaster for users who opened the app in a remote location and found it entirely non-functional. The fix was not just technical. It required designing the offline states as carefully as any other screen.

Create a named offline page, typically /offline.html, and register it as a fallback in your service worker. Serve it whenever a navigation request fails and there is no cached version available. Style it to match your brand completely.

Step 7: Make It Installable

Installation is what separates a PWA from a website that happens to have a service worker. When a user installs a PWA, it appears on their home screen, launches in its own window, and opens without a visible browser address bar. It sits alongside native apps and behaves like one from the outside.

Browsers trigger an install prompt automatically when certain conditions are met: the site is on HTTPS, has a valid manifest, and has a service worker registered. On Android, Chrome shows a banner or a subtle prompt relatively quickly. On iOS, users still need to manually select "Add to Home Screen" from the Safari share menu, iOS does not show an automatic install prompt, which means you need to surface that instruction yourself if installation is something you want to encourage.

The timing of an install prompt, where you have control over it, matters considerably. Showing it the moment someone arrives on the site is the equivalent of asking someone to commit to a restaurant before they have seen the menu. Show it after the user has done something meaningful, completed a purchase, saved a product, finished a workout. At that point, the value of having the app on their home screen is self-evident, and the prompt feels like a natural next step rather than an interruption.

Step 8: Test Across Devices and Network Conditions

Testing a PWA is not the same as testing a website. You need to test under conditions that do not exist in a normal office environment: throttled connections, no connection at all, mid-session disconnection, and reconnection after a period offline. You also need to test across device types, operating systems, and browser versions, because PWA support varies in ways that matter.

Chrome DevTools provides a network throttling panel that lets you simulate slow 3G, offline states, and custom conditions. Use it throughout the build, not just at the end. The Application tab shows you what is registered in your service worker, what is in each cache, and whether the manifest is being read correctly. Lighthouse generates a PWA audit score and flags specific missing requirements.

Test on real devices, not just emulators. The install prompt behaviour on a real Android device differs from what you see in a DevTools simulation. iOS quirks, particularly around caching and storage limits, only show up on actual hardware. If your users are predominantly on mid-range Android devices, test on a mid-range Android device. A flawless experience on a current flagship does not tell you what your actual users experience.

Also test what happens when a service worker update is deployed. The update lifecycle is one of the most common sources of PWA bugs, where users end up on a stale version of the site because the new service worker has not activated. Testing the update flow deliberately, before launch, saves a significant amount of pain later.

The Brand Experience Consequences the Guides Skip Over

A PWA conversion is a technical project that produces a brand experience consequence. When a product moves from browser-tab to home-screen app, the context in which users encounter it changes, and the expectations that come with that context change too. A website visited occasionally through a search result carries different expectations than an icon that sits on someone's home screen. The second one needs to feel like it belongs there.

This matters for lifestyle brands in a way that it does not matter for a utility app. A skincare brand, a supplement company, a wellness product, the emotional quality of the experience is part of what they are selling. A PWA that loads quickly but feels like a bolted-on afterthought, where the tone of voice in the offline screen does not match the tone of voice everywhere else, where the icons are slightly blurry, where the splash screen colour is close but not quite right, all of that erodes something that took real effort and budget to build.

The solution is not to treat the PWA layer as a technical addition to an existing design. It wants to be designed as a coherent experience from the ground up, with every state, loading, offline, installed, first launch, considered as carefully as any other screen. The install prompt copy, the offline page, the splash screen, the home screen icon, these are brand touchpoints. They want the same attention as the homepage hero.

Setting User Expectations Before They Hit Your PWA

One of the clearest lessons from our work on multi-step product flows applies directly to PWA adoption: what you tell users before they start shapes how they experience what follows. On a health and wellbeing product we worked on, we tested two versions of an onboarding flow, one that primed users upfront about what to expect, and one that simply showed a progress bar. Without priming, drop-off rates were around 80 to 85%, typically within the first three or four questions. After introducing upfront priming, telling users what was about to happen before it began, completion rates rose to approximately 95%.

The same principle applies to a PWA install. If users encounter the install prompt without any context for why they are being asked to add this to their home screen, the prompt reads as an interruption. If they arrive at it having already understood what the installed version offers, faster loading, offline access, notifications, the prompt reads as a logical next step.

Simon argued that getting a product listing right so that users who download it already know what they are getting into reduces early abandonment significantly. The logic is the same for a PWA: users who install with correct expectations are far less likely to delete it within the first session. Surface the value proposition before the install prompt. Explain what the offline experience covers. Tell users what they gain by installing rather than just browsing. That framing work happens before any technical step and shapes every retention number that follows.

The Case for Doing Fewer Things Extremely Well

Users who have a bad experience with an app are far less likely to return to it, a pattern Simon has observed consistently when advising travel and lifestyle app teams. The figure is a reason to take the quality ceiling seriously. A PWA that technically supports offline mode but serves a broken, half-rendered offline state when connectivity drops has created a bad experience. The technical box is ticked and the user relationship is damaged.

The alternative is to scope the PWA honestly. Decide which features genuinely need offline support and build those offline states properly. Leave the rest to fail gracefully with a clear, calm message. A travel app that reliably serves saved tickets, itineraries, and maps offline, and says clearly that bookings require connectivity, is a better product than one that attempts to do everything offline and does all of it badly.

We recommended a similar kind of scoping on a surveying app for performance coaches. The original brief assumed a native app download was the right approach. We pushed back. For what was essentially a lightweight touchpoint, a presenter creates a survey, an audience responds, requiring a download was too high a barrier. A QR code leading to a fully branded, mobile-responsive web page removed the friction entirely and produced significantly higher survey completion rates. The lesson was not that PWAs or native apps are wrong. It was that the right scope, clearly defined, beats an ambitious scope executed halfway.

Build the offline states you actually need. Cache the assets that genuinely serve the user in low-connectivity moments. Design every state, loading, offline, installed, as carefully as the main experience. Then stop. The budget saved belongs on the quality of what you have committed to, not on features that exist to complete a checklist.

A limited set of features done properly serves users better than every feature done partially.

Debenhams' PWA, for example, focused on speed and purchase journey simplification. The result was a journey from browsing to purchase that was 2x to 4x faster than before, a 20% increase in conversions, and a 40% increase in mobile revenue, according to Think with Google (though the figures come from a single brand case study published by Google, so they are better read as directional than definitive). The numbers are notable. But what they reflect is a team that picked a clear problem, a slow, friction-heavy mobile purchase journey, and solved that specific problem thoroughly.

Conclusion

Converting a website to a PWA is a technical process with a clear sequence of steps. HTTPS, then a manifest, then a service worker, then a considered cache strategy, then a designed offline experience, then a well-timed install prompt, then thorough testing. Each step is manageable, and the path is well documented.

What is less documented is the work that determines whether the result is worth building. The audit that tells you what the experience actually needs. The scoping decision that draws a clear line between what will work offline and what will fail gracefully. The brand experience work that ensures every state, loading, offline, installed, feels like it belongs to the product. The expectation-setting that shapes how users approach the installed version before they have even opened it.

A PWA done well is a designed experience that uses the technical capabilities of service workers and manifests to serve users better in the moments that matter. The technical steps get you to the starting line. The experience work determines what you actually deliver.

If you are at the point of deciding whether a PWA conversion is right for your product, or if you are part way through and the experience questions are starting to surface, we are happy to work through it with you. Let's talk about your PWA.

Frequently Asked Questions