Skip to content
Search

Progressive web application

lastmod 2025-08-30created 2020-09-2613 edits

Progressive web applications (PWA) are a type of application software delivered through the web, built using common web technologies including HTML, CSS, and JavaScript. They are designed to work on any platform that uses a standards-compliant browser. Their features include working offline, push notifications, device hardware access, and enabling user experiences similar to native applications on desktop and mobile devices. Since they are a type of web page or website known as a web application, developers and users do not need to install the web apps through digital distribution systems such as the Apple App Store or Google Play.

While web applications have been available for mobile devices from the start, they were generally slower, had fewer features, and were used less than native apps. However, with the ability to work offline, previously only available to native apps, PWAs running on mobile devices can perform much faster and provide more features, narrowing the gap with native apps and becoming portable across both desktop and mobile platforms.

PWAs do not require a separate build or distribution process. A progressive web app can be published from any web page.

About

Intro

There is a lot of good free content that explains PWAs well, but misinformation is also widespread. You have probably heard one or more of the following.

  • To build a PWA, you must use a JavaScript framework.
  • To build a PWA, you must start with a single page app (SPA).
  • PWAs only make sense as "apps" that users can install.
  • PWAs are only relevant on mobile.
  • PWAs are an Android thing.

None of these are true. Like much of today's misinformation, each contains a fragment of truth twisted into a falsehood. When building a PWA you might consider a JavaScript framework and a single page app, but you don't have to. Those are just options for PWAs, as for any other web project. After all, a PWA is a website (or rather, it should be). A PWA is simply a traditional website enhanced with a few extra features (for example, "installation"). But likewise, not every PWA needs to be installable. Although early PWAs focused on mobile and only worked on Android, they are no longer limited to small-screen devices. And it's not just Google. Microsoft, Mozilla, Opera, and Samsung have all joined in. Apple recently announced plans to implement Service Worker (one of the foundational technologies of PWAs). Whether it will also support installation remains to be seen, of course. But it doesn't matter. PWAs work fine in Safari anyway!

Unfortunately, this misinformation has convinced many designers and developers (and their management teams) that PWAs are not suitable for their projects. But the opposite is true! Every site should be a PWA. This approach benefits every web project, and I will briefly summarize why in this article. Before that, I want to get everyone on the same page by explaining exactly what a PWA is. If you already know PWAs in detail or have already built one, feel free to skip the next section. If you are not familiar with PWAs at all or don't understand them well, don't worry. The next section will serve as a well-summarized primer to get you up to speed on PWAs quickly.

What exactly is a PWA?

As mentioned earlier, a PWA is a website with special capabilities. The word "app" in "progressive web app" does not limit the type of content or experience users expect from a PWA. Don't get hung up on the term "progressive web app" itself. It's just a marketing term. A PWA has the ability to connect at a deep level with the operating system (and therefore its users). This is made possible through installation and through APIs that provide features such as notifications and contacts access. Not all APIs require installation, but some do. You might find it convenient to think of a PWA as website double plus (website++).

What makes a PWA a true PWA? Not much, actually. These three requirements are all there is.

It must run on HTTPS.
Because PWAs are granted several special permissions by the operating system, a secure connection to the web server is essential. If you need help with this, check out Let's Encrypt, a free SSL service.
It must have a Web App Manifest.
Don't be scared by the name. It is just a JSON file containing information about the site. Moreover, if you use a favicon generator, you probably already have a basic skeleton manifest file. Reference it with a link in the head of the web page so that browsers and search spiders can find it.
It must use a service worker.
This is probably the most complex step. But there are a huge number of guides on service workers, so you can follow a recipe that fits the kind of work you want. Among them, the guide from Mozilla is especially excellent.

That's all. Once you meet the conditions above, the website is a progressive web app. At least technically. But why are these qualifications needed? That probably needs a little more explanation.

When Alex Russell first introduced the concept of PWAs in 2015, he described ten characteristics that all PWAs have in common. Most of them were, without doubt, about how to build websites. But some were neither universal nor suitable for every kind of project. I suspect this is one reason many people considering adopting PWAs have been confused. It is also why I decided to write this article.

Overview of caching flow

Overview_of_caching_flow.jpg

Service worker Debugging

To check whether the service worker served a cached file, look at the browser's developer tools (Network tab).

Chrome-debugging-transferred.png
Firefox-debugging-transferred.png

Chrome

Firefox

What is caching in a PWA?

Unlike browser caching (Cache-Control), it is a technique that caches web resources using the browser's Cache Storage.

Workbox caching strategies

See Workbox#Workbox caching strategies.

Service worker caching strategies

There are five service worker caching strategies.

Strategy

Freshness reasoning

Use cases

Network only

The content must always be up to date.

  • Payments and checkout
  • Balance statements

Network falling back to cache

Serving fresh content is preferable. However, if the network fails or is unstable, serving slightly stale content is acceptable.

  • Timely data
  • Prices and rates (disclaimer required)
  • Order status

Stale-while-revalidate

Serving cached content right away is fine, but updated cached content should be used in the future.

  • News feeds
  • Product listing pages
  • Messages

Cache first, fall back to network

The content is non-critical and can be served from the cache for performance, but the service worker should check for updates occasionally.

  • App shells
  • Common resources

Cache only (only the cache)

The content rarely changes.

  • Static content

Optimizing PWAs for different display modes

Progressive web apps (PWA) are a powerful tool for making web applications feel like native apps, and the user experience can be optimized through various display modes.

  • The display mode set in the PWA's manifest file controls the visibility of the browser UI; adjusting the user interface for each mode eases the gap between the web and app experiences
  • Use CSS media queries and JavaScript to adjust content and features per display mode, providing a tailored experience that meets user needs
  • PWA users and regular website visitors have different expectations, so navigation, install prompts, and content should be optimized per display mode
  • Optimizing per display mode is an important technique that makes PWAs feel more polished and app-like and improves the app experience on the web

PWA display modes and why optimization is needed

  • PWA is a technology for implementing web applications like native apps; leaving the browser environment can cause usability problems
    • Possible loss of browser-provided features such as back, refresh, and copying the URL
    • Elements suitable for a website may feel unnatural in an app environment
  • The display modes that can be set in the manifest file are as follows
    • fullscreen: hides all browser UI and uses the full screen
    • standalone: hides browser controls and looks like a native app
    • minimal-ui: shows a minimal set of browser UI elements
    • browser: provides the standard browser interface
  • Hiding the browser UI can affect the user experience, so optimizing per display mode is essential

Using display mode media queries

  • Media queries can adjust styles and features according to the display mode
    • Example: @media (display-mode: standalone) applies only in standalone mode
    • Queries are supported for fullscreen, minimal-ui, and browser modes respectively
  • The experimental modes window-controls-overlay and tabbed can be set in a custom order via display_override
    • window-controls-overlay: shows window control buttons as an overlay on desktop
    • tabbed: supports multiple application contexts within a single window
  • JavaScript can check the display mode and adjust dynamically
    • Example: check the current mode with window.matchMedia("(display-mode: standalone)").matches
    • Detect events on mode change to adjust the UI dynamically

Practical use cases

  • Content tailored to PWA users: users who installed the PWA are already converted, so reduce marketing content and focus on the user experience
    • Hide unnecessary elements such as install prompts
  • Providing extra options: without browser UI, in-app alternatives are needed for font size adjustment, light/dark mode switching, sharing, etc.
  • Platform-appropriate features: a bottom navigation bar, common in native mobile apps, suits PWAs but feels unnatural on websites
    • Features like a print button are best hidden in PWA mode
  • Managing install prompts: use media queries or JavaScript so install prompts do not appear in an already installed PWA
    • Example: hide elements in PWA mode with a .hide-in-pwa utility class
  • Scope and start URL strategy: differentiate content between the PWA and the web with scope and start_url
    • scope: defines the top-level path of the PWA; outside the scope, the browser UI is shown
    • start_url: specifies the page shown when the app launches, e.g. going straight to a dashboard
  • Enhanced view transitions: apply view transition effects, common in native apps, only to the PWA
    • Example: set view transition CSS within @media (display-mode: standalone)

Browser support and testing

  • Display mode media queries are widely supported in most browsers
    • Firefox does not support PWAs, and Firefox on Android shows them only in browser mode
    • Progressive enhancement ensures graceful degradation in unsupported browsers
  • Behavior differs by device and browser, so testing must be done in various environments
    • Browsers do not provide display mode simulation, so testing on real device and OS combinations is needed

Summary and implications

  • Use display-mode media queries to give PWAs an adaptive experience according to installation and display context
    • Enables hiding install prompts, supporting navigation, tailoring content, enhancing the native feel, and progressive enhancement
  • PWA users have different needs and expectations from regular web visitors, so careful adjustment per display mode is needed
  • As PWAs mature, careful implementation and optimization are key to creating an attractive app experience
  • For more information, Smashing Magazine's "Extensive Guide To Progressive Web Applications" is recommended

Projects

Favorite site

author Zer0 sitemap