Why Businesses Are Turning Websites Into Progressive Web Apps

Most business websites lose their audience the moment the internet connection drops. The page stops loading, the user sees an error or a blank screen, and they move on. For a product page, a service description, or any content that represents the business, that moment of failure is a missed opportunity. A Progressive Web App changes what happens in that scenario by giving the website the ability to work, at least partially, without an active connection.

A Progressive Web App is a website built to standards that allow it to be installed directly onto a mobile device home screen and function like an application. It does not come from an app store. There is no download manager, no update queue, and no submission process to wait through. The website simply meets a set of browser requirements, and the installation option appears automatically for any visitor using a compatible device.

The practical benefits for a UK business website include improved mobile user experience, faster load times for returning visitors, and the ability to serve cached content when connectivity is unreliable. This article explains what a PWA is, what technical components are required, how the platform behaves differently on iOS and Android, and what businesses should realistically expect from the implementation.

The Two Browser Requirements That Make a PWA Work

A website becomes a Progressive Web App when it satisfies two specific conditions that browsers check automatically. The first is a web app manifest file served from the root of the domain. The second is a registered service worker with a functional fetch event handler. Both must be present and correctly configured before the browser will display the installation prompt to the visitor.

The Web App Manifest File

The manifest is a JSON document that tells the browser how to represent the website when it is installed on a device. It defines the name that appears beneath the icon on the home screen, the icon images in multiple sizes, the background colour of the splash screen that briefly displays during launch, and the start URL that determines which page opens when someone taps the installed icon.

The manifest must be linked in the HTML head section of every page that should trigger the PWA installation prompt. Here is a minimal working example:

{
  "name": "Business Name",
  "short_name": "Business",
  "start_url": "/",
  "display": "standalone",
  "background_color": "#ffffff",
  "theme_color": "#0a3d62",
  "icons": [
    {
      "src": "/icons/icon-192.png",
      "sizes": "192x192",
      "type": "image/png"
    },
    {
      "src": "/icons/icon-512.png",
      "sizes": "512x512",
      "type": "image/png"
    }
  ]
}

The display value of standalone is the most important setting for a business website. It removes the browser address bar, navigation controls, and tab bar when the app launches. The result is an experience that looks and feels like a native application rather than a webpage. Other display values exist, but standalone is almost always the appropriate choice for a business presence.

The Service Worker

The service worker is a JavaScript file that runs separately from the main website thread. It intercepts network requests made by the browser, decides whether to serve cached content or fetch new content from the network, and can run in the background even when the website is not open. This separation from the main thread is what enables offline functionality and background processing.

The service worker must be registered in the main JavaScript file or directly in a script tag on the page. Registration is straightforward:

if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/sw.js').then(
    function(registration) {
      console.log('Service Worker registered:', registration.scope);
    },
    function(error) {
      console.log('Service Worker registration failed:', error);
    }
  );
}

The /sw.js file is the service worker itself, and it must exist at the root of the domain. A service worker registered from a subdirectory can only control pages within that subdirectory, so placing it at the root ensures the entire site is covered by the PWA behaviour.

What Offline Functionality Actually Means in Practice

Offline functionality is the feature most commonly associated with Progressive Web Apps, but it is also the most frequently misunderstood. Being offline does not mean the website works fully with no internet connection. It means the browser can serve cached versions of pages and assets that have been previously visited, allowing the user to continue reading content even when a network connection is unavailable.

For a business website, this has practical value in specific scenarios. A user who visited your site on a train through a tunnel, or in a hotel with unreliable WiFi, or in an area with slow mobile data, can still access pages they have already viewed. This matters most for product pages, service descriptions, and blog posts where the content does not change frequently. Caching this content aggressively improves the user experience significantly when connectivity is poor.

Static websites with infrequent content updates are the easiest to make fully offline-capable. A service worker with a cache-first strategy will serve all cached content without attempting a network request, meaning the site works entirely without connectivity once the initial visit has been completed. CDN configuration can complement this by distributing cached assets across multiple edge locations, reducing the load on the origin server and improving delivery speed for users who are geographically distant from the primary server.

What Cannot Be Made Offline

Forms that submit data, checkout processes, live search results, user account information, and any feature that requires a server response cannot function offline without additional engineering. The service worker can queue form submissions for later transmission when connectivity returns, but this adds complexity and should be designed deliberately rather than assumed to work automatically.

For sites that rely heavily on dynamic content, it is generally better to show a clear offline message for pages that require fresh data than to serve stale information that could mislead a customer. The service worker fetch handler can distinguish between different types of requests and apply different caching strategies accordingly.

How Service Worker Caching Strategies Work

The caching strategy applied in the service worker determines the balance between content freshness and offline resilience. The most common strategies are cache-first, network-first, and stale-while-revalidate. Each suits different content types and change frequencies.

Cache-first is appropriate for static assets such as images, stylesheets, JavaScript files, and fonts. The service worker checks the cache before attempting any network request. If the asset is in the cache, it is served immediately. If it is not cached, the network request is made, the response is stored in the cache, and the asset is served. This strategy provides the fastest possible load times for cached content and works fully offline for previously visited assets.

Network-first is appropriate for content that changes frequently and should not be served from cache if a network connection is available. The service worker attempts the network request first, serves the fresh response if available, and falls back to the cache if the network request fails. This strategy ensures the user sees up-to-date content while retaining offline functionality for previously cached pages.

Stale-while-revalidate serves the cached version immediately while simultaneously making a network request to update the cache for the next visit. This strategy is useful for content that does not change very often but should not be served as stale for too long. The user sees a fast cached response, and the cache is updated in the background for future visits.

self.addEventListener('fetch', function(event) {
  if (event.request.method !== 'GET') return;

  event.respondWith(
    caches.match(event.request).then(function(response) {
      return response || fetch(event.request).then(function(networkResponse) {
        caches.open('page-cache').then(function(cache) {
          cache.put(event.request, networkResponse.clone());
        });
        return networkResponse;
      });
    })
  );
});

This fetch handler implements a cache-first strategy for all GET requests. It serves from the cache if available and falls back to the network. It also caches new responses as they come in, so subsequent requests for the same resource are served from the cache immediately without any network delay.

PWA Capabilities on iOS Devices

The iOS platform handles Progressive Web Apps differently from Android in ways that materially affect what functionality is available. Apple restricts several browser features that are standard on Android, and understanding these limitations before committing to a PWA strategy prevents unpleasant surprises during development or after launch.

Service workers on iOS can cache content for offline viewing, but the caching behaviour is less aggressive than on Android devices. iOS imposes storage limits based on available device space and purges cached data under system pressure without warning. A PWA that relies on large offline caches may find those caches partially or completely cleared by iOS at any time.

Push notifications are not supported through the standard web push protocol on iOS. The device can receive push notifications from a PWA only if the PWA is added to the home screen and the user has granted permission, but the notification must still be triggered through Apple proprietary notification infrastructure. In practice, this means push notifications require a native app on iOS to work reliably.

Background sync, which allows the service worker to defer tasks until a network connection is available, is not supported on iOS Safari. If offline data synchronisation is a core requirement, the PWA approach will need supplementing with a native app for iOS users.

Home screen installation works on iOS Safari, and PWAs installed on iOS devices can appear indistinguishable from native apps in terms of launch experience. The app runs in a standalone window without browser chrome, and the icon appears on the home screen. However, the underlying capabilities available to that installed app remain constrained by the iOS Safari feature set.

PWA Capabilities on Android Devices

Android provides a more permissive environment for Progressive Web Apps, particularly when the PWA is installed from Chrome. The browser supports the full web push standard, allowing push notifications through the standard web push protocol without any native app involvement. Background sync is also supported, enabling deferred network requests to complete when connectivity returns.

Android also supports the WebAPK installation flow, which creates a system-level app entry that behaves more like a native app than a simple shortcut. The WebAPK receives a different app icon treatment on Android devices and can appear alongside native apps in the app switcher with a proper app name and icon rather than the browser icon and label.

The Trusted Web Activity integration allows a PWA to be opened without any browser chrome at all when launched from the Android home screen, using the device default browser rather than a custom tab. This provides an experience that is visually indistinguishable from a native app for the majority of common use cases.

Push Notifications: When They Make Sense for a Business

Push notifications require a combination of the service worker infrastructure and a subscription management system on the server side. When a user grants notification permission, the browser generates a push subscription object containing an endpoint URL unique to that user. This endpoint must be stored on the server and used to send push messages via the web push protocol.

For most business websites, push notifications add more complexity than they are worth unless there is a clear reason to interrupt the user with timely information. Appropriate uses include order status updates, appointment reminders, or breaking news relevant to the user's interests. Using notifications for marketing messages without clear value to the user is a fast way to lose notification permission and cause enough irritation that the user uninstalls the PWA.

If notifications are part of the business model, the implementation requires a VAPID key pair, a push library on the server side, and proper handling of subscription expiration and renewal. The Chrome DevTools application panel provides a service worker debugging interface that makes testing push notifications significantly easier during development.

Minimum Technical Requirements for a Business PWA

For a business website that is not primarily an application, the minimum viable PWA implementation requires three components: the manifest file, the service worker with cache handling, and HTTPS on every page. These three things are non-negotiable. HTTPS is required because service workers can only be registered on secure origins. The manifest file is required to trigger the installation prompt. The service worker is required to make offline functionality work.

The icons referenced in the manifest should be generated in at least two sizes. The 192 by 192 pixel version covers most Android devices. The 512 by 512 pixel version is used on higher-density displays and during the splash screen. Failing to provide icons in these sizes is one of the most common PWA implementation mistakes and results in a poor installation experience or no installation prompt at all.

The theme colour in the manifest controls the colour of the browser address bar when the site is open on Android. Setting this to a colour that matches the brand identity is a small detail that meaningfully improves the perceived quality of the installation. The background colour only appears briefly during the splash screen on launch, but an abrupt white flash while the app is loading looks unprofessional.

How PWA Installation Changes Customer Behaviour

The most measurable benefit of a Progressive Web App for a business website is the change in return visit behaviour. Users who install a PWA on their home screen tend to return more frequently than users who only visit the website in a browser tab. A browser tab can be hidden and forgotten. A home screen icon is visible every time the user unlocks their phone.

This increased return frequency translates to more opportunities for engagement, conversion, and brand recall. For content-driven businesses, this is particularly valuable. For e-commerce sites, the lower friction of reopening an installed app versus navigating back to a website in a browser tab can meaningfully affect cart abandonment rates and repeat purchase frequency.

The installation itself should be encouraged but not pushed aggressively. A persistent banner that blocks content or a full-screen interstitial asking for installation is counterproductive and creates a negative user experience. The browser native installation prompt is subtle and appears at an appropriate time. Additional prompts should only be shown after the user has engaged meaningfully with the site, such as after completing a purchase, filling out a contact form, or reading several pages of content.

Common PWA Implementation Mistakes

The most frequent mistake is registering a service worker without a fetch event handler. A service worker that does nothing in response to network requests provides no offline functionality and does not satisfy the PWA installation requirements. The service worker must actively intercept and handle requests to be considered functional by the browser.

Another common mistake is failing to update the cache when website content changes. A service worker that caches pages aggressively but does not have a cache invalidation strategy will continue serving old content long after updates have been published. Using cache versioning or setting cache expiration timestamps in the stored responses allows the service worker to know when to fetch fresh content.

Not testing on real devices is a mistake that causes problems post-launch. Browser developer tools simulate service worker behaviour and offline conditions, but the real interaction between a service worker, the device network stack, and the operating system memory management cannot be fully replicated in a desktop browser. Testing on actual Android and iOS devices, including older and lower-spec devices, is essential for a reliable PWA that works in real-world conditions.

Ongoing Maintenance for a Business PWA

A PWA is not a one-time build. After launch, the service worker needs updating whenever the website design changes, new assets are added, or the caching strategy needs adjustment. The manifest file needs updating when icons or branding change. If the site moves to a new domain, the start URL in the manifest must be updated or the PWA installation will point to the old location.

For businesses that do not have internal technical staff to maintain a PWA, ongoing IT support can cover the updates, monitoring, and troubleshooting needed to keep the PWA functioning correctly after launch. This is particularly relevant when the PWA is a core part of how customers interact with the business. IT documentation practices help ensure that any technical changes to the PWA are recorded properly, making future maintenance simpler and reducing the risk of configuration drift over time.

When a PWA is Not the Right Approach

A Progressive Web App is not a replacement for a native mobile application in situations where the application requires access to device capabilities that are not available through web APIs. Real-time background processing, Bluetooth device communication, precise geofencing, and integration with system-level features beyond what the Web APIs expose are all areas where a native app remains necessary.

If the primary goal is to drive app store visibility and discoverability through search in the app stores, a PWA will not achieve that. App store distribution requires submitting a native application. PWAs are distributed through the web, not through app stores, even though the Apple App Store and Google Play Store have policies that allow wrapping PWAs as native apps if the business chooses that route.

For most business websites, however, a PWA is the right choice. Web development work that includes a PWA implementation costs a fraction of a native application, the maintenance burden is lower because there is no app store submission process, and the install friction is genuinely minimal compared to asking a customer to download and keep updated a native app they may use once a month.

Next Steps for Adding a PWA to Your Business Website

A Progressive Web App is a practical addition to most business websites, particularly those where mobile visitors represent a significant portion of traffic or where offline access to content would be valuable. The core requirements are straightforward: a manifest file, a service worker with a fetch handler, and HTTPS. These three elements unlock the installation prompt, offline caching, and the performance improvements that come with serving cached assets.

If you want a practical review of your current website setup before starting a PWA implementation, you can get in touch with details of your website URL, hosting environment, and the mobile experience you want to improve. I can then assess what is already in place and what work would be needed to meet PWA requirements.