Tutorials Books Videos Forums

Change the theme! Search!
Rambo ftw!

Customize Theme




What are Progressive Web Apps (PWA)?

by kirupa   |   filed under Web Apps

Progressive Web Apps (commonly abbreviated as just PWA) are all the rage these days. Everyone seems to be jumping over each other to take their existing web experiences and giving them a hearty dose of progressiveness. It seems like some well-known brand is regularly announcing that they are building a PWA - brands like Starbucks, Google Maps, Twitter, Uber, and many more:

Over the next few sections, let's get a really good look at what PWAs are why all of us should pay more attention to them...or not :P


A PWA is just a Better Web App

If we take a step back and put aside any of the noise we’ve been hearing about PWAs, they are just plain old web apps (or sites) very similar to the ones we’ve been seeing and building for billions of years. They are built using HTML, CSS, JS and rely on a large ecosystem of tools and frameworks whose stickers are probably featured on the back of your laptop at this very moment. At the end of the day, PWAs look like regular web apps. They smell like regular web apps. They probably even taste like regular web apps.

What this doesn't mean is that every web app is a PWA. Sorry, Yahoo from 1997:

There are a few user experience and technical requirements a web app must meet in order to be a PWA. Let's take a few moments to go deeper into what exactly that means.

PWAs = Great User Experience

One of the hallmarks of PWAs is to reinforce a new vision that the web isn't about terribly bloated content with ads and pop-ups everywhere. The goal is for all of us to collectively move the web forward with a strong focus on doing the right things for our users. This means that PWAs are expected to...

Start Fast. Run Fast.

When a user interacts with a PWA, they aren't experiencing sluggish response times and other artifacts that poorly performing web apps tend to show.

Be Responsive and Adaptive

Our world isn't just big screens with a keyboard and mouse. Pretty much everything with access to a power outlet and a wireless connection is capable of running web content these days:

This means our users will be accessing web content (our web content!) across a variety of devices, form factors, input devices, accessibility modes, and screen sizes! A good PWA will work really well across all of them.

Handle Spotty Connectivity Like a Boss

One of the biggest frustrations with traditional web apps is that they fall apart the moment your internet connection gets flaky:

With PWAs, you account for network flakiness and design the right features to ensure your users don't lose valuable data or can't make progress in whatever they are doing. There are various degrees of offline capabilities you can provide. You can be extremely lazy and just provide a simple offline message like what you'll see on this site:

On the other end, you can be an industrious koala and provide a fully offline-capable version of your content where everything is cached similar to what the lodash documentation does:

Many PWAs will fall somewhere in the middle, but the important thing is that they will acknowledge inconsistent internet connectivity and try to provide the right set of features to help users out.

Borrow Desirable App-Like Features

One of the things you will see in any discussion of PWAs is how they are adopting functionality that once only native apps had. One such functionality is the ability for your PWA to handle push notifications even when your browser is closed and your app is no longer running:

The other functionality is the ability for a PWA to be launched from your default OS launch location (home screen, start menu, dock, etc.) and run inside a native app shell instead of your browser. This means that users won’t just access a PWA via a browser tab:

Instead, if they choose to install the PWA, they can run it just like they would any native stand-alone application. The following screenshot is of this site running as a standalone app, and notice the icon in the dock below:


The exact gesture for installing a PWA varies by browser and operating system, but the end result is always something similar: users have a way of launching and interacting with a PWA in the same way they would a native app on the platform.

What does installing mean here?

The word installing is misleading when it comes to PWAs. All of the app content is still served from your server and, unless you explicitly added some caching capabilities, your PWA will suffer the same challenges it normally would if the network connectivity goes haywire. All that really gets installed on your machine is just the bare minimum information needed to launch your app, like what the app icon should be and the URL to use when starting up.


Technical Improvements a PWA Should Rely On

To help PWAs meet the user experience goals we looked at in the previous section, the web has evolved to help out. While most of the HTML, CSS, and JS advancements made over the years are optional for you to rely on, there are a few technical features your web app absolutely totally 100% for real must use in order to wear the PWA badge.

1. Use HTTPS to serve content securely. This is a straightforward one that you are probably well aware of.

2. Specify a Web Application Manifest to specify additional metadata about your app. In the past, we had meta tags that gave search engines extra details about your content. The Web Application Manifest is like meta tags 2.0:

  "short_name": "KIRUPA",
  "name": "KIRUPA",
  "icons": [
      "src": "/images/orange_192.png",
      "type": "image/png",
      "sizes": "192x192"
      "src": "/images/orange_512.png",
      "type": "image/png",
      "sizes": "512x512"
  "start_url": "/index.html?source=pwa",
  "background_color": "#0099fe",
  "display": "standalone",
  "scope": "/",
  "theme_color": "#0099fe"

By specifying this manifest, you provide additional details about your app that browsers, search engines, and operating systems can use to provide a more native app-like experience. For example, the PWA installation case we looked at earlier relies on the information in this manifest for specifying the appropriate app icon, title, etc.

3. Use a service worker to provide richer caching for offline/low-connectivity situations. A service worker is just a background script that runs even when your browser is no longer running:

Among a few things a service worker does, it allows you to intercept all of your app's network events. This means you can write your own JavaScript to decide whether to allow the network request to go through, block the request, return a file from your cache, handle a push notification, and so on. I'm greatly understating the power that service workers bring to web apps here, so if you really want to learn more about them right now, check out Service Workers: An Introduction.

Is PWA just a Rename of Web Apps?

So, there you have it. A PWA is just a web app that promotes a good user experience, uses HTTPs to securely serve content, provides additional metadata via the web application manifest, and uses a service worker to handle network/caching-related activities. When we look at PWAs in this really concise way, they don't really seem all that awesome, right? Well, yes...and no!

Web technologies have been evolving for a very long time, and we never had to rebrand what we called web apps every time some new API or functionality became available that did something cool. The reason for this new name is best summarized by Frances Berriman who first coined the term Progressive Web Apps. In Naming Progressive Web Apps, she says:

The name [PWA] isn’t for you and worrying about it is [a] distraction from just building things that work better for everyone. The name is for your boss, for your investor, for your marketeer. It’s a way for you to keep making things on the open web, even those things that look really “app-y” and your company wants to actually make as a native app, 3 times over. They don’t want you to make websites anymore, but you still can if you’re sneaky, if you tell them it’s what they think they want.

To echo what Frances says, I saw this first-hand when I was the Product Manager for PWAs at Microsoft and had to work with various internal and external teams on their app strategy. A large reason PWAs got (and continue to get!) so much interest is largely because of the naming. The general name of web apps has been around for a while, and it didn’t exactly have a lot of positive connotations - especially when you compared it to native apps and the level of performance and UX richness they provided. It doesn’t matter that web apps today are light years better than what they were just a few years ago purely based on under-the-hood performance improvements in all the browsers and web runtimes, and a well-built web app runs as smoothly and flawlessly as a native app equivalent. Early impressions are what matter, and many people in the decision making process for your team or company’s app strategy would not give web apps a second look. They probably still reference Mark Zuckerberg's ancient 2012 statement that betting on HTML5 was a mistake. The key word being: 2012.

PWAs, on the other hand, are new and don't carry the historical baggage that web apps are known for. If calling something a web app will incite yawns but calling the same thing a PWA will get rounds of applause, why not just go with the PWA name especially when the people who benefit are your end-users and maybe even your developers?


PWAs are here to stay. While Google initially spearheaded the PWA initiative, today everyone from Samsung, Mozilla, Microsoft, and others work together with everyone else on evolving the next set of features that will make PWAs better. Browser support for the features like Service Worker is slowly approaching full adoption, so if you have been sitting on the fence on implementing some of the PWA featuers this article talked about, you should jump down and get coding!

Just a final word before we wrap up. If you have a question and/or want to be part of a friendly, collaborative community of over 220k other developers like yourself, post on the forums for a quick response!

Kirupa's signature!

The KIRUPA Newsletter

Thought provoking content that lives at the intersection of design 🎨, development 🤖, and business 💰 - delivered weekly to over a bazillion subscribers!


Creating engaging and entertaining content for designers and developers since 1998.



Loose Ends

:: Copyright KIRUPA 2024 //--