The 2020 Web Almanac: PWA

Hemanth HM

Part II Chapter 14

PWA

Date published: 2020/12/09

Last updated: 2022/12/12

Written by Hemanth HM

Reviewed by Pascal Schilp, Jad Joubran, Pearl Latteier, and Gokulakrishnan Kalaikovan

Analyzed and edited by Barry Pollard

Introduction

In 1990 the first ever browser called the “WorldWideWeb” was launched and ever since, the web and the browser have been evolving. For the web to progress itself into native application behavior is a big win especially in this era of mobile domination. URLs and web browsers have provided a ubiquitous way to distribute information and so a technology which provides native app capabilities to the browser is a game changer. Progressive Web Apps provide such advantages for the web to compete with other applications.

Simply put, a web application which give native-like application experience can be considered as a PWA. It is built using common web technologies including HTML, CSS and JavaScript and can operate seamlessly across devices and environments on a standards-compliant browser.

The crux of a progressive web app is the service worker, which can be thought of as a proxy sitting between the browser and user. A service worker gives the developer total control over the network, rather than the network controlling the application.

As last year’s chapter stated, it started in December 2014 when Chrome 40 first implemented the meat of what is now known as Progressive Web Apps (PWA). This was a collaborative effort for the web standards body and the term PWA was coined by Frances Berriman and Alex Russell in 2015.

In this chapter of Web Almanac we will be looking into each of the components that make PWA what it is, from a data-driven perspective.

Service workers

Service workers are at the very center of progressive web apps. They help developers control the network requests.

Service worker usage

From the data we gathered we can see that about 0.88% desktop sites and 0.87% mobile sites use a service worker. This was for the month of August 2020 and, to put that into perspective, that equates to 49,305 (out of 5,593,642) desktop sites and 55,019 (out of 6,347,919) mobile sites.

Figure 14.1. Timeseries of service worker installation.

While that usage may seem low, it is important that we realize that other measurements equate that to 16.6% of the web traffic–the difference being due to high traffic websites tending to use service workers more.

Lighthouse insights

Lighthouse provides automated auditing, performance metrics, and best practices for the web and has been instrumental in shaping web’s performance. We looked at the PWA category audits gathered for over 6,782,042 pages and this has given us great insights on a few important touch points.

Lighthouse Audit	Weight	Percentage
`load-fast-enough-for-pwa`	7	27.97%*
`works-offline`	5	0.86%
`installable-manifest`	2	2.21%
`is-on-https`	2	66.67%
`redirects-http`	2	70.33%
`viewport`	2	88.43%
`apple-touch-icon`	1	34.75%
`content-width`	1	79.37%
`maskable-icon`	1	0.11%
`offline-start-url`	1	0.75%
`service-worker`	1	1.03%
`splash-screen`	1	1.90%
`themed-omnibox`	1	4.00%
`without-javascript`	1	97.57%

Figure 14.2. Lighthouse PWA audits.

Note the performance statistic for our Lighthouse tests were incorrect for our August crawl so the load-fast-enough-for-pwa result has been replaced with September results.

A fast page load ensures a good mobile user experience, particularly when slower cellular networks are taken into consideration. 27.56% of pages loaded fast enough for a PWA. Given how geographically distributed the web is, having a fast load time with lighter pages matter the most of the next billion users of the web, most of whom will be introduced to the internet via a mobile device.

If you’re building a Progressive Web App, consider using a service worker so that your app can work offline 0.92% of pages were offline ready.

Browsers can proactively prompt users to add your app to their home screen, which can lead to higher engagement. 2.21% of pages had an installable manifest. Manifest plays an important role in how the application starts, the looks and feel of the icon on the home screen and as an impact on the engagement rate directly.

All sites should be protected with HTTPS, even ones that don’t handle sensitive data. This includes avoiding mixed content, where some resources are loaded over HTTP despite the initial request being served over HTTPS. HTTPS prevents intruders from tampering with or passively listening in on the communications between your app and your users and is a prerequisite for service workers and many new web platform features and APIs like HTTP/2. The is-on-https check shows that 67.27% of sites were on HTTPS without mixed content and it is surprising that we haven’t reached higher yet. The Security chapter shows that 86.91% of sites are using HTTPS, suggesting that mixed content may be the bigger issue now. This number will get better as browsers mandate the applications to be on HTTPS and scrutinize those which are not on HTTPS more.

If you’ve already set up HTTPS, make sure that you redirect all HTTP traffic to HTTPS in order to enable secure connection the users without changing the URL: only 69.92% of the sites pass this audit. Redirecting all the HTTP to HTTPS on your application should be simple steps towards robustness, though the HTTP redirection to HTTPS has a decent number of sites passing, it can do better.

By adding <meta name="viewport"> tag you optimize your app for mobile screens. 88.43% of the sites have the viewport meta tag. It is not surprising that the usage of viewport meta tag is on the higher side as most developers and tools are aware of viewport optimization.

For ideal appearance on iOS, your progressive web app should define an apple-touch-icon meta tag. It must point to a non-transparent 192px (or 180px) square PNG. 32.34% of the sites pass the apple touch icon check.

If the width of your app’s content doesn’t match the width of the viewport, your app might not be optimized for mobile screens. 79.18% of the sites have the content-width set correctly.

A maskable icon ensures that the image fills the entire shape without being letterboxed when adding the progressive web app to the home screen. Only 0.11% of sites use this, but given that it is a brand new feature, having any usage here is encouraging. As it has just been introduced we were expecting the numbers to be very low and these should improve in the coming years.

A service worker enables your web app to be reliable in unpredictable network conditions. 0.77% of sites have an offline start URL to allow the app to run even when not connected to the network. This is one of the most important features for a PWA, as flaky networks are the most common issue that the users of web applications face.

The service worker is the feature that enables your app to use many Progressive Web App features, such as offline usage and push notifications. 1.05% of pages have service workers enabled. Given the powerful features that can be addressed with service workers, and that it has been supported for some time now, it is surprising that number is still so low.

A themed splash screen ensures a native-like experience when users launch your app from their home screens. 1.95% of pages had splash screens.

The browser address bar can be themed to match your site. 4.00% of pages had themed omnibox.

Your app should display some content when JavaScript is disabled, even if it is just a warning to the user that JavaScript is required to use the app. 97.57% pages show more than just a blank page with JavaScript disabled. Given that we only survey the home pages, it’s perhaps more surprising that 3.43% of sites fail this audit!

Service worker events

In a service worker one can listen for a number of events:

install, which occurs upon service worker installation.
activate, which occurs upon service worker activation.
fetch, which occurs whenever a resource is fetched.
push, which occurs when a push notification arrives.
notificationclick, which occurs when a notification is being clicked.
notificationclose, which occurs when a notification is being closed.
message, which occurs when a message sent via postMessage() arrives.
sync, which occurs when a background sync event occurs.

We have examined which of these events are being listened to by service workers in our dataset.

Figure 14.3. Most used service worker events.

The results for mobile and desktop are very similar with install, fetch, and activate being the three most popular events, followed by message, notification click, push and sync. If we interpret these results, offline use cases that service workers enable are the most attractive feature for app developers, far ahead of push notifications. Due to its limited availability, and less common use case, background sync doesn’t play a significant role at this time.

Web app manifests

The web app manifest is a JSON-based file that provides developers with a centralized place to put metadata associated with a web application. It dictates how the application should behave on desktop or mobile in terms of the icon, orientation, theme color and likes.

In order for a PWA to be fruitful it needs to have a manifest and a service worker. It is interesting to note that manifests are used a lot more than service workers. This is due, in large part, to the fact that CMS like WordPress, Drupal and Joomla have manifests by default.

Figure 14.4. Manifest and service worker usage.

Having a web app manifest does not necessarily indicate the site is a progressive web app, as they can exist independently of service worker usage. However, as we are interested in PWAs in this chapter, we have investigated only those manifests for sites where a service worker also exists. This is different than the approach taken in last year’s PWA chapter which looked at overall manifest usage, so you may notice some differences in results this year.

Manifest Properties

Web manifest dictates the applications meta properties. We looked at the different properties defined by the Web App Manifest specification, and also considered non-standard proprietary properties.

According to the spec, the following properties are valid properties:

background_color
categories
description
dir
display
iarc_rating_id
icons
lang
name
orientation
prefer_related_applications
related_applications
scope
screenshots
short_name
shortcuts
start_url
theme_color

There were very little differences between mobile and desktop stats.

The proprietary properties we encountered frequently were gcm_sender_id used by Google Cloud Messaging (GCM) service. We also found other interesting attributes like: browser_action, DO_NOT_CHANGE_GCM_SENDER_ID (which was basically a comment, used as JSON doesn’t allow comments), scope, public path, cacheDigest.

On both platforms, however, there’s a long tail of properties that are not interpreted by browsers yet contain potentially useful metadata.

We also found a non-trivial number of mistyped properties; our favorite ones being variation of theme-color, Theme_color, theme-color, Theme_color and orientation.

Top Manifest display values

Most used display values for service worker pages. — Figure 14.6. Most used `display` values for service worker pages.

Out of the five most common display values, standalone dominated the list with 86.73% of desktop and 89.28% of mobile pages using this. This isn’t surprising at all as this mode provides the native app-like feel. Next in the list was minimal-ui with 6.30% of desktop and 5.00% of mobile sites opting for them. This is similar to standalone except for the fact that some browser UI is retained.

Top manifest categories

Out of all the top categories, shopping stood at the top at with 13.16% on the mobile traffic, which is not unexpected as PWAs are e-commerce applications. news was next with 5.26% on the mobile traffic.

Manifests preferring native

Figure 14.8. Manifest preferring native.

98.24% of desktop PWA sites and 98.52% of mobile PWA sites set the preferred_related_applications manifest property to not prefer native apps, but instead use web version where they exist. For the small percentage where this is set to true this is a signal that there are many web applications that just have a manifest but aren’t really full PWAs yet.

Top manifest icon sizes

Bar chart showing the top icon sizes with 192 by 192 pixels being used by 19.10% of desktop sites and 19.76% of mobile sites, similar numbers for the next size of 512 by 512 pixels with 18.21% and 18.85%. This is followed by a sharp drop for 96 by 96 pixels having 7.21% for desktop and 7.11% for mobile, and then it continues to drop roughly linearly for the remaining values of 72 by 72 pixels, 48 by 48 pixels, 128 by 128 pixels, 152 by 152 pixels, 384 by 384 pixels, 256 by 256 pixels, 36 by 26 pixels, 196 by 196 pixels, 120 by 120 pixels, 168 by 168 pixels, 32 by 32 pixels until we get to 16 by 16 pixels used by 0.89% of desktop sites and 0.81% of mobile sites.

Figure 14.9. Top manifest icon sizes.

Lighthouse requires at least an icon sized 192x192 pixels, but common favicon generation tools create a plethora of other sizes, too. It is always better to use the recommended icon sizes for each device so it is encouraging to see such a widespread usage of different icon sizes.

Top manifest orientations

The valid values for the orientation property are defined in the Screen Orientation API specification. Currently, they are:

any
natural
landscape
portrait
portrait-primary
portrait-secondary
landscape-primary
landscape-secondary

Out of which we noticed that portrait, any and portrait-primary properties took precedence.

Service worker libraries

There are many cases, where the service workers use libraries as dependencies, be it external dependencies or the application’s internal dependencies. These are usually fetched to the service worker via the importScripts() API. In this section we will look into stats on such libraries.

Popular import scripts

The importScripts() API of the WorkerGlobalScope interface synchronously imports one or more scripts into the worker’s scope. The same is used to import external dependencies to the service worker.

Script	Desktop	Mobile
Uses `importScripts()`	29.60%	23.76%
`Workbox`	17.70%	15.25%
`sw_toolbox`	13.92%	12.84%
`firebase`	3.40%	3.09%
`OneSignalSDK`	4.23%	2.76%
`najva`	1.89%	1.52%
`upush`	1.45%	1.23%
`cache_polyfill`	0.70%	0.72%
`analytics_helper`	0.34%	0.39%
Other Library	0.27%	0.15%
No Library	58.81%	64.44%

Figure 14.11. PWA library usage.

Around 30% of desktop PWA sites and 25% of mobile PWA sites uses importScripts(), of which workbox, sw_toolbox and firebase take the first three positions respectively.

Workbox usage

Out of many libraries available, Workbox was the most heavily used with an adoption rate of 12.86% and 15.29% of PWA sites on mobile and desktop respectively.

Figure 14.12. Most used Workbox packages.

Out of many methods that Workbox provides, we noticed that strategies were used by 29.53% of desktop and 25.71% on mobile, routing followed it with 18.91% and 15.61% adoption and finally precaching were next most used with 16.54% and 12.98% on desktop and mobile respectively.

This indicated that the strategies API, as one of the most complicated requirements for the developers, played a very important role when they decided to code themselves or rely on libraries like Workbox.

Conclusion

The stats in this chapter show that PWAs are still continuing to grow in adoption, due to the advantages they give for performance and greater control over caching particularly for mobile. With those advantages and ever increasing capabilities, means we still have a lot of potential for growth. We expect to see even more progress in 2021!

More and more browsers and platforms are supporting the technologies powering PWAs. This year, we saw that Edge gained support for the Web App Manifest. Depending on your use case and target market, you may find that the majority of your users (close to 96%) have PWA support. That is a great improvement! In all cases, it is important to approach technologies such as service workers and Web App Manifest as progressive enhancements. You can use these technologies to provide an exceptional user experience and, with the above stats, we’re excited for another year of PWA growth!

PWA