PWA

Learn more

PWA stands for Progressive Web App. It is an application built with web technologies that runs in a browser and can also be installed on supported devices and launched much like a traditional mobile or desktop application.

A PWA combines the reach of a website with selected capabilities commonly associated with installed applications. It can have its own icon, open in a separate window, store data locally, provide limited offline functionality, and use notifications or other device features when they are supported by the browser and operating system and permitted by the user.

What does Progressive Web App mean?

A Progressive Web App is a web application whose capabilities can be enhanced according to the user’s device and browser. Core functionality should remain available in a regular browser, while supported environments can provide additional features such as installation, standalone display, offline operation, and push notifications.

The word “progressive” is related to progressive enhancement. The application should provide essential value across a broad range of environments and then use more advanced capabilities where they are available.

How does a PWA work?

A PWA is based on standard web technologies such as HTML, CSS, and JavaScript. Its files are delivered by a web server and processed by the browser engine. This allows a single codebase to support different operating systems and types of devices.

A typical PWA may include:

a responsive interface designed for different screen sizes;
a secure HTTPS connection;
a web app manifest;
logic supporting installation and standalone launching;
a service worker when caching, offline operation, notifications, or background tasks are required;
local data storage;
a backend and an API when the application exchanges data with a server.

Installation criteria and available capabilities vary between browsers and operating systems. A PWA should therefore not assume that every feature will behave identically on every device.

Web app manifest

A web app manifest is a file containing information that describes the application. It usually uses the .webmanifest or .json extension and is connected to the HTML document using a <link rel="manifest"> element.

The manifest can define:

the application’s full and short names;
a unique application identifier;
the URL opened when the application starts;
the navigation scope belonging to the application;
the preferred display mode;
background and theme colors;
icons in different sizes;
screen orientation;
shortcuts to selected features;
supported file types or protocols where the platform allows them.

A simplified manifest may look like this:

{
  "id": "/",
  "name": "Example Application",
  "short_name": "Example",
  "start_url": "/",
  "scope": "/",
  "display": "standalone",
  "background_color": "#ffffff",
  "theme_color": "#000000",
  "icons": [
    {
      "src": "/icons/icon-192.png",
      "sizes": "192x192",
      "type": "image/png"
    },
    {
      "src": "/icons/icon-512.png",
      "sizes": "512x512",
      "type": "image/png"
    }
  ]
}

A manifest alone does not turn a website into a complete PWA. It gives the browser information required to identify, present, and install the application, while other capabilities require appropriate code and architecture.

What is a service worker?

A service worker is a JavaScript file that runs separately from the open page’s interface. It can act as an intermediary between the application, local cache, and network. It cannot access the DOM directly, but it can communicate with open pages and respond to specific events.

A service worker can be used to:

intercept network requests;
store resources in a cache;
serve saved files when the network is unavailable;
display an offline fallback page;
receive push messages;
defer selected operations until connectivity returns;
handle certain background tasks;
manage the application update process.

A service worker is often one of the most important components of an advanced PWA, but it is not universally required merely for installation. Browser installation criteria have changed over time and vary between platforms.

Can a PWA work offline?

A PWA can work offline, but the extent of its offline functionality depends on how it has been designed. Adding a manifest or registering a service worker does not automatically make the entire application available without an internet connection.

An offline experience may provide:

the application’s core interface;
previously cached pages;
saved images, stylesheets, and scripts;
data stored locally on the device;
forms that will be submitted after connectivity returns;
a clear explanation of which features require internet access.

Features that depend on current server data, authorization, payments, inventory verification, or communication with other users may remain unavailable offline. A well-designed PWA explains these limitations and prevents users from losing information they have entered.

PWA caching strategies

A service worker can use different strategies to retrieve and store resources. The appropriate strategy depends on the type of information and how current it needs to be.

Common caching strategies include:

cache first – the application checks the cache first and uses the network only when the resource has not been saved;
network first – the application first attempts to retrieve current data from the network and falls back to a cached version if the request fails;
stale while revalidate – the cached version is displayed immediately while an updated version is downloaded for future use;
network only – data must always come from the server;
cache only – only locally stored resources are used.

An inappropriate strategy can result in outdated prices, inventory levels, documents, or account information. Data that affects transactions or security usually needs to be confirmed by the server.

How is a PWA installed?

A supporting browser may promote PWA installation or provide an installation option in its menu. On mobile devices, the application can be added to the home screen. On desktop systems, it may appear in an application menu, Dock, taskbar, or desktop environment.

Once installed, a PWA may:

have its own application icon;
launch without the browser’s standard address bar;
open in a separate window;
appear in the operating system’s application list;
handle links within its defined scope;
provide shortcuts to selected actions;
be uninstalled by the user.

The installation process is not identical across platforms. Some browsers display a dedicated prompt, while others require the user to select an add or install option manually. A PWA can provide concise, device-specific guidance without preventing people from using the service when they do not want to install it.

Can a PWA be published in an app store?

The web is the primary distribution channel for a PWA. Users can open the application through a standard URL and use it without visiting an app store.

In some cases, a PWA can also be prepared for distribution through selected app stores by using an intermediary solution or a package required by the relevant platform. This is not automatic and may involve additional configuration, packaging, compliance with store policies, and a review process.

App store publication is not required for a PWA to operate. A business should determine whether store availability provides meaningful value to its users and justifies the additional maintenance.

PWA vs. a traditional website

A traditional website is normally accessed by entering its address or following a link from a search engine. A PWA remains part of the web, but it can provide a more application-like way to use the service.

Compared with a standard website, a PWA may offer:

installation on the device;
its own icon and launch experience;
standalone window operation;
partial offline access;
advanced local data storage;
push notifications;
selected background operations;
integration with supported operating system features.

Not every website needs these capabilities. An informational site, a simple company website, or a small landing page may gain little business value from a complete PWA implementation.

PWA vs. responsive web design

Responsive web design adapts an interface to different screen sizes. PWA describes a broader web application model that includes installation, reliability, and integration with the user’s device.

Responsiveness is an important foundation for a PWA, but a responsive website does not automatically become a PWA. Similarly, an application with a manifest and service worker will not provide a good application experience if it performs poorly on mobile devices.

PWA vs. SPA

An SPA, or Single Page Application, updates much of its interface and navigation without fully reloading the HTML document. PWA concerns installation, reliability, and capabilities provided by the web platform.

A PWA can be built as an SPA, but this is not required. It can also use traditional pages rendered by the server. Likewise, an SPA does not automatically become a PWA merely because it provides a dynamic browser-based interface.

PWA vs. a native application

A native application is built for a particular operating system, such as Android or iOS, using platform-specific technologies and development tools. A PWA is delivered through the web and runs through a browser engine.

Potential PWA advantages include:

a single codebase supporting multiple platforms;
no mandatory installation before the first use;
distribution through an ordinary link;
updates published directly to the server;
the ability to make public content searchable;
a lower initial cost for certain projects;
no requirement to publish through an app store.

A native application may provide:

broader and more predictable access to device capabilities;
better support for complex background operations;
greater control over operating system integration;
higher performance in computationally demanding use cases;
access to features unavailable through web APIs;
more consistent behavior within a particular platform.

A PWA is not automatically a less expensive replacement for every native application. The decision should reflect user needs, required integrations, offline requirements, performance, budget, and distribution strategy.

PWA vs. a hybrid application

A hybrid application uses web technologies inside a native container and is installed as a package built for a particular platform. The container can expose additional device functionality to JavaScript through dedicated modules.

A PWA does not require this type of container and can be used directly through a web address. A hybrid application may have broader access to platform features, but it requires appropriate packages to be built, signed, and distributed.

Which device features can a PWA use?

Available capabilities depend on the browser, operating system, hardware, and permissions granted by the user. In supporting environments, a web application may use:

geolocation;
the camera and microphone;
push notifications;
the system clipboard;
native sharing interfaces;
limited access to the local file system;
selected file handling capabilities;
badges displayed on the application icon;
full-screen display;
network status information;
selected Bluetooth, USB, or NFC devices where an appropriate web API is supported.

A critical user journey should not depend exclusively on a feature available in only one browser. Compatibility should be verified before development, and a fallback method should be provided where possible.

Push notifications in a PWA

A PWA can send push notifications after obtaining the user’s informed permission. Notifications may be used to communicate an order status change, a new message, an upcoming appointment, or another event that requires attention.

The permission request should not appear immediately after the first visit without explaining the benefit. It is better to request permission in the context of a relevant feature and allow the application to remain usable when the user declines.

Notifications should be useful, expected, and easy to disable. Excessive frequency, unwanted promotional content, or a difficult opt-out process can cause users to block notifications or lose trust in the application.

Key benefits of a PWA

Potential PWA benefits include:

access through a link without mandatory installation;
installation on supported devices;
a shared codebase for multiple platforms;
fast deployment of updates;
reduced dependence on app stores;
improved operation during unreliable connectivity;
a shorter path from discovery to using the service;
integration with the website’s public content;
search engine access to properly implemented public pages;
appropriate re-engagement through notifications;
a consistent environment across mobile and desktop devices.

These benefits do not appear automatically when a manifest is added. They depend on interface quality, performance, stability, offline strategy, user value, and the suitability of the technology for the actual process.

PWA limitations

A PWA may also have significant limitations:

different levels of feature support across browsers and operating systems;
less access to certain device features than native applications;
restrictions on background operation;
dependence on browser storage policies;
the possibility that local data will be removed by the system or user;
an inconsistent installation process;
reduced app store visibility when the PWA is not published through a store;
the need to test multiple browser engines;
the risk of displaying outdated data when caching is misconfigured;
no guarantee that experimental web APIs will remain available in the same form.

Before selecting PWA technology, a team should list all critical capabilities and verify their actual support on the devices used by the target audience.

PWA security

A PWA should be served over HTTPS. An encrypted connection reduces the risk of data being intercepted or modified in transit and is required for many advanced web platform capabilities. Local development environments are a common exception.

HTTPS and an SSL certificate do not provide complete security on their own. An implementation should also address:

secure authentication and session management;
server-side access control;
input validation;
protection against XSS, CSRF, and other web attacks;
secure storage of tokens and local data;
an appropriately limited service worker scope;
regular updates to libraries and dependencies;
API protection;
a suitable Content Security Policy;
regular security testing;
a process for invalidating a defective or compromised release.

Sensitive information should not be cached without a risk assessment. The device may be shared, lost, or accessed by another person.

Privacy and user permissions

Access to location, camera, microphone, notifications, and other device capabilities should be requested when the user intentionally starts a feature that needs it. The interface should explain why access is required and what will happen if permission is denied.

A PWA should collect only the data required for defined purposes. The implementation must account for data protection principles, retention periods, withdrawal of consent, and account or data deletion where required by law or the nature of the service.

PWA performance

Performance is a foundation of a good PWA experience. Installability does not fix a heavy interface, excessive scripts, or a slow backend.

Optimization may include:

reducing JavaScript and CSS size;
splitting code into components loaded when needed;
compressing images and using modern formats;
lazy-loading noncritical resources;
optimizing web fonts;
using browser and service worker caching appropriately;
limiting third-party scripts;
optimizing API requests;
rendering critical content without a long JavaScript delay;
monitoring results on real user devices.

A PWA should also be tested on entry-level phones, slower connections, and devices with limited memory. Results from a developer’s high-performance computer do not represent the conditions experienced by every user.

PWA UX and accessibility

A PWA should provide understandable and predictable UX both in the browser and after installation. When browser controls are removed, the application must provide clear navigation, a way to go back, effective error handling, and information about its current state.

Accessibility considerations include:

semantic HTML structure;
keyboard support;
visible focus indicators;
sufficient color contrast;
clear form labels;
error messages available to assistive technologies;
text alternatives for visual content;
support for text enlargement;
reduced motion based on user preferences;
appropriate focus management in dynamic interfaces;
clear communication of connectivity changes and unavailable features;
adequately sized touch targets.

A PWA remains a web application and should meet the applicable WCAG requirements. Installation does not change the accessibility principles that apply to its content and interface.

PWA and SEO

Public PWA content can be made available to search engines like other web resources. This requires meaningful URLs, internal links, metadata, semantic HTML, and content that crawlers can process.

Problems may occur when all content is generated only after complex JavaScript executes, individual views have no unique URLs, or the server returns the same empty document for every request. Depending on the architecture, server-side rendering, static generation, or another method can be used to provide complete content.

A service worker should not return incorrect, outdated, or identical responses for different URLs. The application should also preserve appropriate HTTP status codes, redirects, canonical URLs, and sitemap handling.

Updating a PWA

PWA code is generally updated on the server without requiring the user to download a new package manually. A service worker has its own lifecycle, however, so a new version may be installed in the background and wait before taking control of the application.

The update process should address:

cache versioning;
removal of unused resources;
compatibility between the new interface and older locally stored data;
migration of browser database structures;
notification of an available update when appropriate;
protection against losing data entered into an unfinished form;
the ability to roll back a defective release;
testing situations in which different application versions are active at the same time.

Forcing an immediate reload whenever an update is detected can interrupt the user’s work. The deployment process should reflect the type of product and the risk associated with using outdated code.

PWA for e-commerce

In an online store, a PWA can make it easier to browse products, return to a cart, use the store with unreliable connectivity, and receive order updates.

Potential applications include:

installing the store on the home screen;
opening previously visited categories more quickly;
saving selected preferences locally;
preserving a cart before the customer signs in;
sending order status notifications;
displaying recently viewed products;
saving form data during a temporary connection failure;
supporting a loyalty program or customer account.

Prices, discounts, availability, delivery costs, and final order totals should be confirmed by the server. Cached data must not become the authoritative source for outdated transaction terms.

A PWA can be connected to platforms such as WooCommerce, but the required work depends on the theme, plugins, payment methods, cart behavior, and external integrations.

PWA and WordPress

A website built with WordPress can be extended with PWA capabilities. Available plugins may generate a manifest, register a basic service worker, or create an offline fallback page, but installing a plugin does not guarantee the quality of the resulting application.

An implementation should consider:

compatibility with the website’s existing caching system;
exclusion of administration and private pages from unsafe caching;
sign-in and sign-out behavior;
dynamic page fragments;
forms and security tokens;
WooCommerce carts and checkout processes;
theme and plugin updates;
multilingual content;
analytics and consent management integrations;
testing after every significant website change.

Advanced projects may require a custom caching strategy, manifest, installation interface, and update process.

How should PWA performance be measured?

The implementation should be evaluated against its business purpose rather than installation numbers alone. Installing an application does not prove that a user regularly returns or receives meaningful value from it.

Depending on the product, a business may analyze:

installation prompts, starts, and completions;
the percentage of users operating in installed mode;
return frequency;
time required to complete the primary task;
the conversion rate;
processes successfully completed with poor connectivity;
service worker and cache errors;
successful synchronization of deferred operations;
notification permissions and opt-outs;
engagement with notifications;
performance in browser and installed modes;
retention over time;
changes in orders, bookings, or other critical actions.

Analytics may distinguish between browser and installed display modes when this information is needed to evaluate the implementation. Measurement must respect privacy requirements and the user’s consent choices.

When is a PWA a good choice?

A PWA may be appropriate when:

the service is frequently used on both mobile and desktop devices;
users regularly return to the same process;
fast access without searching for the website is valuable;
internet connectivity may be unreliable;
some information can be made available offline safely;
the business wants to support multiple platforms from one codebase;
users are reluctant to install an application before trying the service;
link-based distribution is important for customer acquisition;
required device capabilities are available through web technologies;
the business wants to combine a public website and application within one environment.

PWAs can be used for booking systems, e-commerce platforms, customer portals, SaaS tools, field service systems, educational applications, information services, and internal business applications.

When might a PWA be insufficient?

Another technology may be more appropriate when the product requires:

complete and predictable access to specialized device capabilities;
continuous background operation;
high-performance graphics or data processing;
deep integration with a particular operating system;
features unavailable in the target browsers;
distribution exclusively through a specific app store;
compliance requirements that cannot be met in a web environment;
identical behavior for every feature across all supported platforms.

Before making a final decision, the team may need to perform a feasibility study or build a Proof of Concept for the most technically uncertain capabilities.

How much does it cost to build a PWA?

The cost depends on the condition of the existing website, feature scope, interface design, offline logic, integrations, security requirements, and number of supported platforms. Adding a basic manifest and offline page is a much smaller task than building a complete application with data synchronization, user accounts, payments, and notifications.

The budget may include:

requirements and compatibility analysis;
UX and interface design;
changes to the existing frontend;
manifest and icon preparation;
service worker implementation;
caching strategy development;
local storage and data synchronization;
API integrations;
a notification system;
security and accessibility testing;
cross-device testing;
analytics;
documentation and ongoing maintenance.

A PWA should not be estimated merely as “adding an application to the home screen.” Installation is only one part of the complete solution.

How should a PWA be tested?

Testing should cover both regular browser usage and operation after installation. At minimum, the team should examine:

manifest and icon validity;
installation on supported platforms;
launching from the application icon;
navigation within and outside the application’s scope;
the first launch without an existing cache;
subsequent online and offline launches;
operation during slow or intermittent connectivity;
service worker updates;
removal of outdated cache versions;
behavior after browser data is cleared;
sign-in, sign-out, and user switching;
protection of private data;
denial of individual permissions;
keyboard and assistive technology support;
performance on lower-powered devices;
forms, payments, and other critical processes;
returning to the application after a long period of inactivity.

Automated tools can identify some problems, but they do not replace testing on real devices and in realistic usage scenarios.

Common PWA implementation mistakes

Common mistakes include:

calling a website a PWA solely because it has a manifest;
treating installation as the project’s only objective;
caching every response without considering its purpose;
storing private user information insecurely;
displaying outdated prices or inventory information;
failing to design a clear offline state;
losing user input during a temporary connection failure;
forcing installation before the service can be used;
requesting notification permission immediately;
failing to support users who deny a permission;
assuming that every browser provides the same capabilities;
not testing service worker updates;
leaving obsolete files in the cache;
automatically reloading the application while the user is working;
ignoring SEO, accessibility, or standard web navigation;
building a heavy interface that only looks like an application;
failing to measure meaningful business outcomes.

Can every website be converted into a PWA?

Many existing websites can be progressively enhanced with PWA features without rebuilding the entire system. The required work depends on the current architecture, performance, responsiveness, security, and code quality.

The process may include:

auditing the existing website;
identifying processes that should provide an application-like experience;
checking required capabilities in target browsers;
implementing HTTPS and improving responsive behavior;
preparing the manifest and icons;
selecting caching strategies;
adding a service worker;
designing the offline experience;
implementing the update process;
testing installation, security, and accessibility;
measuring user behavior after launch.

A website does not need to support every possible PWA capability from the beginning. Development can proceed incrementally as long as each implemented feature solves a specific user problem and is tested appropriately.

PWA and web application development

PWA is not a separate programming language or a single technology. It is an approach to designing and delivering web applications using a collection of browser standards and APIs.

A well-designed PWA should remain useful as a website, operate reliably under supported conditions, and provide enhanced capabilities where the device genuinely supports them. Its value does not come from having an icon on the home screen alone, but from combining the reach of the web, the convenience of an installed application, and a well-designed user journey.