What Is a Progressive Web App? a Beginners Guide to PWAs

If you’ll forgive the cliché, when it comes to technology – as with life – the only constant is change. Websites today look very different – and are able to do a whole lot more – than the very first website published in 1990. Similarly, the mobile phones we now use are capable of so much more than that 17-year old cult favourite, the Nokia 3310. We no longer use browsers to only access web pages, but also web apps, while the apps we load on our mobile phones could be either native, or hybrid. And soon it might be neither.

Progressive Web Apps (PWAs) is a term – first used in 2015 – to describe the combined use of modern technologies, design concepts, and Web APIs to provide an app-like experience on the mobile web. More importantly, they are device-agnostic, and run inside modern web browsers, with no need to first download anything from an app store.

Obviously, there is a lot more to Progressive Web Apps that can’t be covered in a simplified summary, so read on to become more familiar with a term you’ll be encountering a lot more in the coming months.

Progressive Web Apps in action

Despite being a relatively new development, many large brands have already started implementing Progressive Web Apps, and some have already attributed amazing results to their PWAs.

Twitter

The Twitter Lite Progressive Web App became the default mobile browser experience for all users in April 2017. The benefit to Twitter included:

65% increase in pages per session
75% increase in Tweets sent
20% decrease in bounce rate

While users benefited from an experience that used less than 3% of the device storage space compared with the Android native app and more impressively helped reduce data consumption by as much as 70%. And when you’re browsing using mobile data as opposed to WiFi, this is significant. The reduced data consumption also opens up the Twitter experience to those on slower connections, which really matters when 45% of connections still use 2G.

AliExpress and Lancôme

Mobile commerce is growing three times faster than e-commerce, but AliExpress had trouble creating a mobile web experience that was as fast as their mobile app, while Lancôme had trouble converting on mobile. Both brands addressed this by creating a PWA, and

Both brands addressed this by creating a PWA, and AliExpress saw:

a 104% increase in conversions for new users across all browsers, with an 82% increase in iOS conversion rates
2X more pages visited per session per user, across all browsers
a 74% increase in time spent per session across all browsers

And Lancôme experienced:

a 17% increase in conversions
a 53% increase in mobile sessions on iOS
an 8% increase in conversion rates on recovered carts via Push Notifications, with an 18% open rate from Push Notifications

Forbes

Progressive Web Apps aren’t limited only to social networks and e-commerce sites, as demonstrated by Forbes, who replaced their mobile site with a PWA enabled site, leading to:

a 43% increase in sessions per user
3X the scroll depth compared with the traditional mobile site
2X the average user session duration
pages that load in 0.8s, down from 3 -12 seconds

So where did progressive web apps come from?

Before dissecting Progressive Web Apps, we have to first revisit web apps – without the modifier. The earliest websites, like much of the web in the early 90s, weren’t terribly dynamic or interactive. They also weren’t that common, with the limitations of CGI curtailing wide-scale adoption.

The introduction of scripting languages and frameworks such as ASP, ColdFusion, and PHP helped move things forward, but it was only following the common adoption of Ajax that web applications started to become truly dynamic. The use of Ajax made it easier to create asynchronous websites that were capable of sending data to, and retrieving data from, a web server in the background. Websites using Ajax were able to update and change content on a page dynamically, without having to reload the page at all.

Early adopters of Ajax included Google – in the first releases of Gmail and Maps – and Kayak.

But this leap forward was not entirely flawless. The shortcomings of Ajax included…

Reduced functionality if a user has JavaScript disabled in their browser, or is using a browser that does not support JavaScript.
Early browsers also had problems registering dynamically generated pages, resulting in erratic behaviour when using the back button, and making it difficult to bookmark pages.
With the exception of Google, most web crawlers were unable to execute JavaScript, making content on pages that use Ajax inaccessible.

There were workarounds for these problems, but they often ended up making the code of the web technology even more complex…

Without Ajax we might have been spared the Web 2.0 label that also entered popular use in 2004. But we would probably have had to wait longer for many of the web apps we now use daily without even thinking of them as web apps: YouTube, Facebook, Twitter, almost anything Google, Evernote, Dropbox, and more.

But the arrival of smartphone operating systems (iOS, Android, and very briefly Windows Phone) complicated things. Each of the web apps listed above, and many others not mentioned here, now also have a mobile app counterpart. And while larger brands such as Google and Facebook have the resources to manage continued development of web apps in addition to an iOS and Android app, the same can’t be said for new startups, SMBs, and independent developers.

Favouring one smartphone OS over another was once feasible, but now, even though Android’s global market share far exceeds that of iOS, iOS still leads in certain key regions. Meaning if you are developing an app that you want to succeed in almost all markets, you have little choice but to develop for both Android and iOS. Which finally brings us to progressive web apps.

How are Progressive Web Apps different?

Further enhancements of web apps did not stall after the introduction of Ajax. JavaScript continued to mature, and the introduction of JavaScript frameworks and libraries helped web apps become even more dynamic. But they were now operating alongside mobile apps, and as society moved to spending more time on mobile devices than desktop devices, the limitations of web apps became more obvious.

The biggest difference, initially, was that native apps – apps designed specifically for iOS and Android – offered a better user-experience. They could be accessed faster, and performance overall was smoother than that offered by a web app on a mobile device. Many native apps could still be used even with no internet connection, could still update information even when running in the background, and – with proper use of push notifications – could have higher engagement rates.

Continued development of CSS3 and JavaScript, the finalisation of HTML5, along with more powerful browsers and processors paved the way for hybrid apps, leading ultimately to Progressive Web Apps. First introduced by Frances Berriman and Alex Russell in a 2015 blog post, Progressive Web Apps differ from native, hybrid, and regular web apps in that:

They work on any mobile device with a supported browser, regardless of operating system, and even the slowest of connections.
They do not need to be downloaded and installed via an app store.
Even though they are not native or hybrid apps, they can still be added to your home screen.
Unlike regular web apps, they continue to update information even when running in the background.

To be fair, Berriman and Russel were giving a name to something that already existed, but they took it further a year later by setting forth some baseline criteria for web apps in order for them to be considered Progressive Web Apps.

They must originate from a secure origin and sent over TLS (sometimes referred to as SSL), and they must not include any mixed content.
They must be able to load while offline (even if it is only a custom offline page). This means that Progressive Web Apps require Service Workers.
They must reference a manifest with at least the following properties:
- name
- short_name
- start_url
- display with a value of standalone or full screen
- An icon at least 144×144 large in png format. E.g.: “icons”: [ { “src”: “/images/icon-144.png”, “sizes”: “144×144”, “type”: “image/png” } ]

Google is now heavily involved in Progressive Web Apps, helping to shape standards, while also building support for these standards into Chrome. They have published a Progressive Web Apps checklist which lists all the things they believe a Progressive Web App should have, both as a baseline and as an ideal. Their baseline expands on the original by including the following:

They must be responsive on tablets and mobile devices.
First load must be fast, even on 3G.
Site must work cross-browser.
Page transitions should be “snappy”, even on slow connections.
Each page must have a URL.
The Web App Manifest must now also include metadata before it can be added to the home screen.

What makes progressive web apps awesome?

There are several reasons for Progressive Web Apps being so awesome that they are being talked about so much that they risk becoming an annoying buzzword. These include:

They cost less, and are faster to develop and deploy, than native and hybrid apps. Most PWAs can be implemented using your current web framework, with little to no need for additional programming languages and technologies.
The app will be easy to expand with new functionality if needed. Many of the current key features – push notifications, pinning to the home screen, sync in the background, offline functionality – are meant to emulate an ‘app-like’ experience, supported by an app-like look and feel.
PWAs are cross-platform, so there’s almost no need to adapt it for different devices, especially if you’ve paid extra attention to responsiveness.
Fully supported by Google, with other key browser developers rapidly coming on board.
You’re able to get your app to market faster since there’s no need to first submit to the Google Play store, or the Apple App Store.
They are fully indexable by search engines, so no need for extra app store marketing efforts.
Less friction in getting users to use the app.

Expanding on these further, the key characteristics of PWAs – over and above the baseline criteria – are that they should be:

Progressive – they must work for every user, regardless of browser choice because they’re built with progressive enhancement as a core principle. Progressive enhancement means that the core content (and features) will always be available regardless of browser or connection speed. More advanced presentation and functional features are only added if supported by the browser.
Responsive – they must fit any form factor: desktop, mobile, tablet, or forms yet to emerge, without requiring any specific action on the user’s part.
Connectivity independent – through the use of service workers, they must work offline, and on low-quality networks. Offline functionality can be limited to certain features only.
App-like – they must feel like an app to the user, with app-style interactions and navigation, all of which should also be snappy and smooth.
Fresh – they must always be up-to-date thanks to the service worker update process. This is dependent on the user being connected to the internet.
Safe – they can only be served via HTTPS, preventing man-in-the-middle attacks, and ensuring that content hasn’t been tampered with.
Discoverable – they must be identifiable as “applications” through the inclusion of a W3C compliant web app manifest, and the service worker registration scope, allowing search engines to find them. This gives PWAs a significant advantage over native apps, which are not searchable.
Re-engageable – they can make re-engagement easy through features like push notifications. However, use of push notifications is a feature, not a requirement.
Installable – they must allow users to “keep” any apps they find most useful on their home screen, without the hassle of an app store.
Linkable – they should be easy to share via a URL, and not require a complex installation.

The Tech Behind Progressive Web Apps

As noted earlier, PWAs are mostly standard HTML5, CSS3, and JavaScript. Two technologies that combine with this to ‘create’ a PWA are web app manifests and service workers.

Web app manifests

A web app manifest is a simple JSON file that controls how the app appears to users on a mobile device, directs what the user can launch, and defines the app appearance at launch. Some of the things you can control include:

whether or not to use the browser’s UI, including the address bar.
the use of a splash screen. When launching a PWA from the home screen, a few things need to happen. Without the use of a splash screen, the screen would go white and appear to have stalled.
the page orientation. Very few apps need to run in landscape mode, but if yours does, it enhances the UX if you enforce this at launch.
Set the theme colour. You can save a lot development time by setting the theme colour in the manifest instead of making changes site wide. This controls the colour of various UI elements, ensuring they closely match the colours of your website.

The web app manifest is also used by Chrome to determine whether or not to display a Web App Install Banner, and is referenced in your HTML through the following addition

<link rel=”manifest” href=”/manifest.json”>

Service workers

A Google engineer, Jeff Posnick, described service workers as:

An air traffic controller… Think of your web apps requests as planes taking off. Service Worker is the air traffic controller that routes the requests. It can load from the network or even from the cache.

It is a script file that runs independently of your web site, and it is this file that allows your app to work even when not connected to the internet, while also controlling background sync. It is also used for push notifications, and will also control future PWA features such as geofencing, etc. PWAs are able to work offline because one of the functions of service workers is to automatically cache assets specified by you. And remembering how one of Google’s baseline criteria for a PWA is that it is served over TLS, service workers can only be registered on sites served securely.

Google has developed an open-source tool for auditing the performance and quality of any web page, including Progressive Web Apps. While it is a great tool to audit any website, it is especially useful if you decide to adapt your website as a Progressive Web App. As highlighted earlier in this article, there are certain criteria that need to be met in order for a website to be recognised as a PWA, but overall performance is especially important since PWAs are intended for users on a mobile device. However, don’t focus only meeting the criteria and passing the Lighthouse audit, because in doing so there is always the risk that you ignore user-experience.

Disadvantages of Progressive Web Apps

The biggest disadvantage of PWAs is that they aren’t currently supported by all mobile browsers. Google’s baseline criteria does state “a site must work cross-browser” (emphasis added), and since much of the PWA is developed using standard HTML5, etc. they will. What is currently lacking in Safari and Microsoft Edge is support for service workers. Service workers aren’t needed for the site to operate properly, only for the app-like features.

But since Chrome dominates in almost all markets, this shouldn’t be a deterrent from investing in a PWA now. Support for service workers is in development for Microsoft Edge, and has now also shown up in WebKit, although this doesn’t guarantee that it will be supported by Safari Mobile anytime soon.

Additionally, service workers currently only support push notifications and background sync, with features found in many business related apps – like geofencing – notably absent. However, this too should not be a deterrent since PWAs are still relatively new, but with Google supporting and hyping them, we can expect to see lots of features common to native apps being added in the near future. And hopefully, this will also include the ability to access system features, and the ability to interact with other PWAs.

It should be noted that Google is already automatically adding an Android wrapper to some PWAs, meaning that on Android devices they can show up in the Apps screen. Similarly, Microsoft is also testing adding a Windows wrapper to some PWAs. These apps are then added to the Windows Store, and appear as apps in Bing search results. Meaning that Google and Microsoft are already seeing PWAs as being equal to native apps. In a recent blog post, Berriman responded to criticism over the term Progressive Web Apps, and he ends off by reminding us that (emphasis added):

PWAs are just a bunch of technologies with a zingy-new brand name that keeps the open web going a bit longer, that helps it compete with the proprietary, the closed, until the next thing (and hopefully the next thing) comes along to keep it sharp and relevant. It’s for the next billion users who come online and open a browser and go looking for what’s out there, for those users who have to pay per mb for their downloads, who have old phones, who don’t want to, or can’t, be on a native-app-based operating system.

Conclusion

Progressive Web Apps are – for want of a better phrase – a new technology, but one that has already demonstrated incredible benefits, not least of which is the lower development cost compared to native apps. Reaching your full audience with a native app requires developing two apps, one for iOS and one for Android. Add to that the cost of ongoing maintenance to ensure it works with each new OS version, along with some backward compatibility for users with an older OS. With a PWA you only develop or adapt a single version of your website/web app: users with a browser that doesn’t fully support PWAs can still access your site, they just won’t get the full app-like experience. And as shown by the real-world examples above, there are almost immediate benefits for both you as a business owner, and for your audience.

To learn more about the PWA features supported by AppInstitute, click here.