From d5578a80c9110e6e5eb51f67dd25499f458b46cd Mon Sep 17 00:00:00 2001 From: Barry Date: Thu, 31 Oct 2019 12:29:49 +0000 Subject: [PATCH 01/11] Copyeditting of PWA chapter --- src/content/en/2019/pwa.md | 119 ++++++++++++++++++++++--------------- 1 file changed, 70 insertions(+), 49 deletions(-) diff --git a/src/content/en/2019/pwa.md b/src/content/en/2019/pwa.md index ae35d1bcc37..733ed00b0d7 100644 --- a/src/content/en/2019/pwa.md +++ b/src/content/en/2019/pwa.md @@ -6,12 +6,14 @@ authors: [tomayac, jeffposnick] reviewers: [hyperpress, ahmadawais] --- +![](https://github.com/HTTPArchive/almanac.httparchive.org/raw/master/src/static/images//2019/11_PWA/hero_xl.jpg) + ## Introduction Progressive Web Apps (PWA) are a new class of web applications, building on top of platform primitives like the [Service Worker APIs](https://developer.mozilla.org/en/docs/Web/API/Service_Worker_API). Service workers allow apps to support network-independent loading by acting as a network proxy, intercepting your web app's outgoing requests, and replying with programmatic or cached responses. -Service workers can receive push notifications, and synchronize data in the background even when +Service workers can receive push notifications and synchronize data in the background even when the corresponding app is not running. Additional, service workers — together with [Web App Manifests](https://developer.mozilla.org/en-US/docs/Web/Manifest) — allow users to install PWAs to their devices’ home screens. @@ -25,16 +27,6 @@ Certain advanced APIs like [Background Sync](https://developers.google.com/web/u are currently still [only available on Chromium-based browsers](https://caniuse.com/#feat=background-sync), so as an additional question, we looked into which features these PWAs actually use. - -All data in the HTTP Archive can be [queried through BigQuery](https://github.com/HTTPArchive/legacy.httparchive.org/blob/master/docs/bigquery-gettingstarted.md), -where multiple tables are available in the `httparchive` project. As these tables tend to get fairly big, -they are partitioned, but multiple associated tables can be queried using the [wildcard symbol '*'](https://cloud.google.com/bigquery/docs/querying-wildcard-tables). -For our research, three families of tables are relevant: - -- `httparchive.lighthouse.*`, which contains data about [Lighthouse](https://developers.google.com/web/tools/lighthouse/) runs. Note that Lighthouse data is only available for mobile pages. -- `httparchive.pages.*`, which contain the JSON-encoded parent documents’ HAR data. -- `httparchive.response_bodies.*`, which contains the raw response bodies of all resources and sub-resources of all sites in the archive. - ## Service Workers ### Service Worker Registrations and Installability The first metric we explore are service worker installations. Looking at the data exposed through @@ -44,27 +36,32 @@ impressive, but taking traffic data from Chrome Platform Status into account, we [a service worker controlled 15% of all page loads](https://www.chromestatus.com/metrics/feature/timeline/popularity/990), which can be interpreted as popular, high-traffic sites increasingly having started to embrace service workers. -``` ``` + **Figure 1:** Service Worker installation over time for desktop and mobile -Looking at Lighthouse data in the HTTP Archive, 1.56% of mobile pages are [installable](https://developers.google.com/web/tools/lighthouse/audits/install-prompt), -that is, they pass Lighthouse’s *user can be prompted to install the web app* test. -Lighthouse tests currently are only available for mobile pages. To control the install experience, -0.82% of all desktop and 0.94% of all mobile pages use the [`OnBeforeInstallPrompt` interface](https://w3c.github.io/manifest/#beforeinstallpromptevent-interface). +Lighthouse checks whether a page is eligble for an [install prompt](https://developers.google.com/web/tools/lighthouse/audits/install-prompt) +though it currently is only available for mobile pages. Looking at Lighthouse data in the HTTP Archive, 1.56% of mobile pages have an +[installable manifest](https://web.dev/installable-manifest/). Readers may notice this is higher than the 0.37% of mobile pages that +register a service worker, which is also a requirement of the install prompt +([issue raised to make this clearer in the documentation](https://github.com/GoogleChrome/web.dev/issues/1797)). +The difference in these numbers may be due to Service Workers being registered on pages other than the home page as the [Web Almanac +only is restricted just to home pages](../methodology). + +To control the install experience, 0.82% of all desktop and 0.94% of all mobile pages use the [`OnBeforeInstallPrompt` interface](https://w3c.github.io/manifest/#beforeinstallpromptevent-interface). At present [support is limited to Chromium based browsers](https://caniuse.com/#feat=web-app-manifest). ### Service Worker Events In a service worker one can [listen for a number of events](https://developers.google.com/web/fundamentals/primers/service-workers/lifecycle): -- `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. +- `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 we could find in the HTTP Archive. The results for mobile and desktop are very similar with `fetch`, `install`, and `activate` being the three @@ -73,11 +70,11 @@ cases that service workers enable are the most attractive feature for app develo push notifications. Due to its limited availability, and less common use case, background sync doesn’t play a significant role at the moment. -``` ``` + **Figure 2a:** Service worker events on mobile, ordered by decreasing frequency. -``` ``` + **Figure 2b:** Service worker events on desktop, ordered by decreasing frequency. @@ -90,11 +87,11 @@ We note that these stats don’t account for dynamically imported scripts throug [`importScripts()`](https://developer.mozilla.org/en-US/docs/Web/API/WorkerGlobalScope/importScripts) method, which likely skews the results higher. -``` ``` + **Figure 3a:** Percentiles of service worker file sizes on mobile. -``` ``` + **Figure 3b:** Percentiles of service worker file sizes on desktop. @@ -120,46 +117,46 @@ frequently were `gcm_sender_id` and `gcm_user_visible_only` from the legacy Google Cloud Messaging (GCM) service. Interestingly there’re almost no differences between mobile and desktop. On both platforms, however, there’s a long tail of properties that are not interpreted by browsers but that contain potentially useful metadata like `author` or `version`. We also found -a non-trivial amount of mistyped properties, our favorite being `shot_name`. An interesting outlier -is the `serviceworker` property which is standard, but not implemented by any browser vendor — +a non-trivial amount of mistyped properties; our favorite being `shot_name`. An interesting outlier +is the `serviceworker` property, which is standard but not implemented by any browser vendor — nevertheless, it was found on 0.09% of all web app manifests used by mobile and desktop pages. -`````` + **Figure 4a:** Web App Manifest properties ordered by decreasing popularity on mobile. -`````` + **Figure 4b:** Web App Manifest properties ordered by decreasing popularity on desktop. ### Display Values Looking at the values developers set for the `display` property, it becomes immediately clear -that they want PWAs to be perceived as “proper” apps that don’t reveal their web technology origins. +that they want PWAs to be perceived as “proper” apps that don’t reveal their web technology origins. By choosing `"standalone"`, they make sure no browser UI is shown to the end-user. This is reflected by the majority of apps that make use of the `prefers_related_applications` property: more that 97% of both mobile and desktop applications do *not* prefer native applications. -```<11_04c mobile>``` +<11_04c mobile> **Figure 5a:** Values for the `display` property on mobile. -```<11_04c desktop>``` +<11_04c desktop> **Figure 5b:** Values for the `display` property on desktop. ### Category Values The `categories` member describes the expected application categories to which the web application belongs. -It is only meant as a hint to catalogs or stores listing web applications, and it is expected that +It is only meant as a hint to catalogs or app stores listing web applications, and it is expected that these will make a best effort to find appropriate categories (or category) under which to list the web application. There were not too many manifests that made use of the property, but it is interesting to see the shift from *shopping* being the most popular category on mobile to *business*, *technology*, and *web* (whatever may be meant with that) on desktop that share the first place evenly. -```<11_04d mobile>``` +<11_04d mobile> **Figure 6a:** Values for the `categories` property on mobile. -```<11_04d desktop>``` +<11_04d desktop> **Figure 6b:** Values for the `categories` property on desktop. @@ -170,33 +167,34 @@ Lighthouse’s rule is probably the culprit for 192×192 being the most popular desktop and mobile, despite [Google’s documentation](https://developers.google.com/web/fundamentals/web-app-manifest#icons) additionally explicitly recommending 512×512, which doesn’t show as a particularly prominent option. -```<11_04f mobile>``` +<11_04f mobile> **Figure 7a:** Popular icon sizes on mobile. -```<11_04f desktop>``` +<11_04f desktop> **Figure 7b:** Popular icon sizes on desktop. ### Orientation Values -The valid values for the `orientation` property are [defined](https://www.w3.org/TR/screen-orientation/#dom-orientationlocktype) -in the Screen Orientation API specification. Namely there are `"any"`, `"natural"`, `"landscape"`, -`"portrait"`, `"portrait-primary"`, `"portrait-secondary"`, `"landscape-primary"`, and `"landscape-secondary"`. +The valid values for the `orientation` property are +[defined in the Screen Orientation API specification](https://www.w3.org/TR/screen-orientation/#dom-orientationlocktype). +Namely there are `"any"`, `"natural"`, `"landscape"`, `"portrait"`, `"portrait-primary"`, `"portrait-secondary"`, +`"landscape-primary"`, and `"landscape-secondary"`. Portrait orientation is the clear winner on both platforms, followed by any orientation. -```<11_04g mobile>``` +<11_04g mobile> **Figure 8a:** Popular orientation values on mobile. -```<11_04g desktop>``` +<11_04g desktop> **Figure 8b:** Popular orientation values on desktop. ## Workbox -Workbox is a set of libraries that help with common service worker use cases. For instance, Workbox has tools -that can plug in to your build process and generate a manifest of files, which are then precached by your -service worker. Workbox includes libraries to handle runtime caching, request routing, cache expiration, -background sync, and more. +[Workbox](https://developers.google.com/web/tools/workbox) is a set of libraries that help with common service worker +use cases. For instance, Workbox has tools that can plug in to your build process and generate a manifest of files, +which are then precached by your service worker. Workbox includes libraries to handle runtime caching, request routing, +cache expiration, background sync, and more. Given the low-level nature of the service worker APIs, many developers have turned to Workbox as a way of structuring their service worker logic into higher-level, reusable chunks of code. Workbox adoption is also @@ -206,3 +204,26 @@ driven by its inclusion as a feature in a number of popular JavaScript framework The HTTP Archive shows that, out of the total population of sites that register a service worker, 12.71% of them are using at least one of the Workbox libraries. This percentage is roughly consistent across desktop and mobile, with a slightly lower percentage (11.46%) on mobile compared to desktop (14.36%). + +## Conclusion +The stats in this chapter show that PWAs are still only used by a small percentage of sites. However this relatively small usage +is driven by the more popular sites which have a much larger share of traffic, and pages beyond the home page may use this more: +we showed that 15% of page loads use a service workers. + +PWAs have also often been seen as Google-driven technology and while the other browsers still have some way to go to catch up on +it's support it's positive to see support becoming more widespread. [Maximiliano Firtman](https://twitter.com/firt) does a great +job of tracking this, including +[explaining Safari PWA support](https://medium.com/@firt/iphone-11-ipados-and-ios-13-for-pwas-and-web-development-5d5d9071cc49) +in light of poor documentation from Apple on that front. He (amongst others) also questions whether the tech giants really want +to support this technology. Apple doesn't use the term PWA much, and has [explicitly stated that it does not want these apps +listed in their App Store](https://developer.apple.com/news/?id=09062019b). Microsoft went the opposite direction not only +[encouraging PWAs in it's app store, but even automatically indexing any found when as it craweled the web] +(https://docs.microsoft.com/en-us/microsoft-edge/progressive-web-apps/microsoft-store), though with it moving on from the Windows + Phone platform the future of that is uncertain. Google has also + [made moves to accepting PWAs in its app store](https://medium.com/@firt/google-play-store-now-open-for-progressive-web-apps-ec6f3c6ff3cc) + though Maxim questions + [Android's commitment to the PWA compared to Chrome](https://medium.com/@firt/is-there-a-cold-war-between-android-and-chrome-because-of-pwas-e50a7471056c). + + Even though progress on supporting PWAs is slower than we'd like, adoption is increasing. We may not quite have hit the point where + PWAs are mainstream yet but the advantages they give for [performance](../performance) and greater control over [caching](../caching), + particualrly for [mobile](../mobile) could soon lead to an explosion in use - perhaps 2020 is the year for this? From 3bdb17a6ed4713852fea93df1e6b98ed7c5db628 Mon Sep 17 00:00:00 2001 From: Barry Date: Thu, 31 Oct 2019 13:53:21 +0000 Subject: [PATCH 02/11] Fix chapter links and other consistency changes --- src/content/en/2019/pwa.md | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-) diff --git a/src/content/en/2019/pwa.md b/src/content/en/2019/pwa.md index 733ed00b0d7..db4809eedcd 100644 --- a/src/content/en/2019/pwa.md +++ b/src/content/en/2019/pwa.md @@ -6,9 +6,8 @@ authors: [tomayac, jeffposnick] reviewers: [hyperpress, ahmadawais] --- -![](https://github.com/HTTPArchive/almanac.httparchive.org/raw/master/src/static/images//2019/11_PWA/hero_xl.jpg) - ## Introduction + Progressive Web Apps (PWA) are a new class of web applications, building on top of platform primitives like the [Service Worker APIs](https://developer.mozilla.org/en/docs/Web/API/Service_Worker_API). Service workers allow apps to support network-independent loading by acting as a network proxy, @@ -28,7 +27,9 @@ are currently still [only available on Chromium-based browsers](https://caniuse. so as an additional question, we looked into which features these PWAs actually use. ## Service Workers + ### Service Worker Registrations and Installability + The first metric we explore are service worker installations. Looking at the data exposed through feature counters in the HTTP Archive, we find that 0.44% of all desktop and 0.37% of all mobile pages register a service worker, and both curves over time are steeply growing. Now this might not look overly @@ -46,7 +47,7 @@ though it currently is only available for mobile pages. Looking at Lighthouse da register a service worker, which is also a requirement of the install prompt ([issue raised to make this clearer in the documentation](https://github.com/GoogleChrome/web.dev/issues/1797)). The difference in these numbers may be due to Service Workers being registered on pages other than the home page as the [Web Almanac -only is restricted just to home pages](../methodology). +only is restricted just to home pages](./methodology). To control the install experience, 0.82% of all desktop and 0.94% of all mobile pages use the [`OnBeforeInstallPrompt` interface](https://w3c.github.io/manifest/#beforeinstallpromptevent-interface). At present [support is limited to Chromium based browsers](https://caniuse.com/#feat=web-app-manifest). @@ -79,6 +80,7 @@ play a significant role at the moment. **Figure 2b:** Service worker events on desktop, ordered by decreasing frequency. ### Service Worker File Sizes + File size or lines of code are in general a bad proxy for the complexity of the task at hand. In this case, however, it is definitely interesting to compare (compressed) file sizes of service workers for mobile and desktop. The median service worker file on desktop is 895 bytes, whereas on mobile it’s 694 bytes. @@ -96,7 +98,9 @@ which likely skews the results higher. **Figure 3b:** Percentiles of service worker file sizes on desktop. ## Web App Manifests + ### Web App Manifest Properties + The web app manifest is a simple JSON file that tells the browser about a web application and how it should behave when installed on the user's mobile device or desktop. A typical manifest file includes information about the app name, icons it should use, the start URL @@ -130,6 +134,7 @@ nevertheless, it was found on 0.09% of all web app manifests used by mobile and **Figure 4b:** Web App Manifest properties ordered by decreasing popularity on desktop. ### Display Values + Looking at the values developers set for the `display` property, it becomes immediately clear that they want PWAs to be perceived as “proper” apps that don’t reveal their web technology origins. By choosing `"standalone"`, they make sure no browser UI is shown to the end-user. This is reflected @@ -145,6 +150,7 @@ of both mobile and desktop applications do *not* prefer native applications. **Figure 5b:** Values for the `display` property on desktop. ### Category Values + The `categories` member describes the expected application categories to which the web application belongs. It is only meant as a hint to catalogs or app stores listing web applications, and it is expected that these will make a best effort to find appropriate categories (or category) under which to list the @@ -161,6 +167,7 @@ interesting to see the shift from *shopping* being the most popular category on **Figure 6b:** Values for the `categories` property on desktop. ### Icon Sizes + Lighthouse [requires](https://developers.google.com/web/tools/lighthouse/audits/manifest-contains-192px-icon) at least an icon sized 192×192, but common favicon generation tools create a plethora of other sizes, too. Lighthouse’s rule is probably the culprit for 192×192 being the most popular choice of icon size on both @@ -176,6 +183,7 @@ additionally explicitly recommending 512×512, which doesn’t show as a particu **Figure 7b:** Popular icon sizes on desktop. ### Orientation Values + The valid values for the `orientation` property are [defined in the Screen Orientation API specification](https://www.w3.org/TR/screen-orientation/#dom-orientationlocktype). Namely there are `"any"`, `"natural"`, `"landscape"`, `"portrait"`, `"portrait-primary"`, `"portrait-secondary"`, @@ -191,6 +199,7 @@ Portrait orientation is the clear winner on both platforms, followed by any orie **Figure 8b:** Popular orientation values on desktop. ## Workbox + [Workbox](https://developers.google.com/web/tools/workbox) is a set of libraries that help with common service worker use cases. For instance, Workbox has tools that can plug in to your build process and generate a manifest of files, which are then precached by your service worker. Workbox includes libraries to handle runtime caching, request routing, @@ -206,6 +215,7 @@ The HTTP Archive shows that, out of the total population of sites that register across desktop and mobile, with a slightly lower percentage (11.46%) on mobile compared to desktop (14.36%). ## Conclusion + The stats in this chapter show that PWAs are still only used by a small percentage of sites. However this relatively small usage is driven by the more popular sites which have a much larger share of traffic, and pages beyond the home page may use this more: we showed that 15% of page loads use a service workers. @@ -225,5 +235,5 @@ listed in their App Store](https://developer.apple.com/news/?id=09062019b). Micr [Android's commitment to the PWA compared to Chrome](https://medium.com/@firt/is-there-a-cold-war-between-android-and-chrome-because-of-pwas-e50a7471056c). Even though progress on supporting PWAs is slower than we'd like, adoption is increasing. We may not quite have hit the point where - PWAs are mainstream yet but the advantages they give for [performance](../performance) and greater control over [caching](../caching), - particualrly for [mobile](../mobile) could soon lead to an explosion in use - perhaps 2020 is the year for this? + PWAs are mainstream yet but the advantages they give for [performance](./performance) and greater control over [caching](./caching), + particualrly for [mobile](./mobile) could soon lead to an explosion in use - perhaps 2020 is the year for this? From 206e6aadad85246afaf4e2c967fb682701cb87db Mon Sep 17 00:00:00 2001 From: Barry Date: Thu, 31 Oct 2019 15:21:49 +0000 Subject: [PATCH 03/11] Edits to generate HTML --- src/content/en/2019/pwa.md | 32 ++++++++++++++++---------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/src/content/en/2019/pwa.md b/src/content/en/2019/pwa.md index 316c3ff135c..3335af5bab8 100644 --- a/src/content/en/2019/pwa.md +++ b/src/content/en/2019/pwa.md @@ -35,9 +35,9 @@ feature counters in the HTTP Archive, we find that 0.44% of all desktop and 0.37 register a service worker, and both curves over time are steeply growing. Now this might not look overly impressive, but taking traffic data from Chrome Platform Status into account, we can see that about [a service worker controlled 15% of all page loads](https://www.chromestatus.com/metrics/feature/timeline/popularity/990), -which can be interpreted as popular, high-traffic sites increasingly having started to embrace service workers. +which can be interpreted as popular, high-traffic sites increasingly having started to embrace service workers. - +`````` **Figure 1:** Service Worker installation over time for desktop and mobile @@ -71,11 +71,11 @@ cases that service workers enable are the most attractive feature for app develo push notifications. Due to its limited availability, and less common use case, background sync doesn’t play a significant role at the moment. - +`````` **Figure 2a:** Service worker events on mobile, ordered by decreasing frequency. - +`````` **Figure 2b:** Service worker events on desktop, ordered by decreasing frequency. @@ -89,11 +89,11 @@ We note that these stats don’t account for dynamically imported scripts throug [`importScripts()`](https://developer.mozilla.org/en-US/docs/Web/API/WorkerGlobalScope/importScripts) method, which likely skews the results higher. - +`````` **Figure 3a:** Percentiles of service worker file sizes on mobile. - +`````` **Figure 3b:** Percentiles of service worker file sizes on desktop. @@ -125,11 +125,11 @@ a non-trivial amount of mistyped properties; our favorite being `shot_name`. An is the `serviceworker` property, which is standard but not implemented by any browser vendor — nevertheless, it was found on 0.09% of all web app manifests used by mobile and desktop pages. - +`````` **Figure 4a:** Web App Manifest properties ordered by decreasing popularity on mobile. - +`````` **Figure 4b:** Web App Manifest properties ordered by decreasing popularity on desktop. @@ -141,11 +141,11 @@ By choosing `"standalone"`, they make sure no browser UI is shown to the end-use by the majority of apps that make use of the `prefers_related_applications` property: more that 97% of both mobile and desktop applications do *not* prefer native applications. -<11_04c mobile> +```<11_04c mobile>``` **Figure 5a:** Values for the `display` property on mobile. -<11_04c desktop> +```<11_04c desktop>``` **Figure 5b:** Values for the `display` property on desktop. @@ -158,11 +158,11 @@ web application. There were not too many manifests that made use of the property interesting to see the shift from *shopping* being the most popular category on mobile to *business*, *technology*, and *web* (whatever may be meant with that) on desktop that share the first place evenly. -<11_04d mobile> +```<11_04d mobile>``` **Figure 6a:** Values for the `categories` property on mobile. -<11_04d desktop> +```<11_04d desktop>``` **Figure 6b:** Values for the `categories` property on desktop. @@ -174,11 +174,11 @@ Lighthouse’s rule is probably the culprit for 192×192 being the most popular desktop and mobile, despite [Google’s documentation](https://developers.google.com/web/fundamentals/web-app-manifest#icons) additionally explicitly recommending 512×512, which doesn’t show as a particularly prominent option. -<11_04f mobile> +```<11_04f mobile>``` **Figure 7a:** Popular icon sizes on mobile. -<11_04f desktop> +```<11_04f desktop>``` **Figure 7b:** Popular icon sizes on desktop. @@ -190,11 +190,11 @@ Namely there are `"any"`, `"natural"`, `"landscape"`, `"portrait"`, `"portrait- `"landscape-primary"`, and `"landscape-secondary"`. Portrait orientation is the clear winner on both platforms, followed by any orientation. -<11_04g mobile> +```<11_04g mobile>``` **Figure 8a:** Popular orientation values on mobile. -<11_04g desktop> +```<11_04g desktop>``` **Figure 8b:** Popular orientation values on desktop. From 030c314325a4cf6a98cb0d3385dfaf9aecb333ea Mon Sep 17 00:00:00 2001 From: Barry Date: Thu, 31 Oct 2019 15:22:21 +0000 Subject: [PATCH 04/11] HTML version --- src/templates/en/2019/chapters/pwa.html | 96 +++++++++++++++---------- 1 file changed, 59 insertions(+), 37 deletions(-) diff --git a/src/templates/en/2019/chapters/pwa.html b/src/templates/en/2019/chapters/pwa.html index 1a8c5ecc743..c9a662ba0a3 100644 --- a/src/templates/en/2019/chapters/pwa.html +++ b/src/templates/en/2019/chapters/pwa.html @@ -67,6 +67,10 @@

Index

  • Workbox
    • + +
  • + Conclusion +
    • @@ -85,7 +89,7 @@

    Introduction

    like the Service Worker APIs.
    Service workers allow apps to support network-independent loading by acting as a network proxy,
    intercepting your web app's outgoing requests, and replying with programmatic or cached responses.
    - Service workers can receive push notifications, and synchronize data in the background even when
    + Service workers can receive push notifications and synchronize data in the background even when
    the corresponding app is not running. Additional, service workers — together with
    Web App Manifests —
    allow users to install PWAs to their devices’ home screens. @@ -100,17 +104,6 @@

    Introduction

    are currently still only available on Chromium-based browsers,
    so as an additional question, we looked into which features these PWAs actually use.

    -

    - All data in the HTTP Archive can be queried through BigQuery,
    - where multiple tables are available in the httparchive project. As these tables tend to get fairly big,
    - they are partitioned, but multiple associated tables can be queried using the wildcard symbol '*'.
    - For our research, three families of tables are relevant: -

    -
      -
    • httparchive.lighthouse.*, which contains data about Lighthouse runs. Note that Lighthouse data is only available for mobile pages.
      • -
    • httparchive.pages.*, which contain the JSON-encoded parent documents’ HAR data.
      • -
    • httparchive.response_bodies.*, which contains the raw response bodies of all resources and sub-resources of all sites in the archive.
      • -

    Service Workers

    Service Worker Registrations and Installability

    @@ -124,24 +117,27 @@

    Service Worker Registra

    <timeseries chart of 11_01b>

    Figure 1: Service Worker installation over time for desktop and mobile

    - Looking at Lighthouse data in the HTTP Archive, 1.56% of mobile pages are installable,
    - that is, they pass Lighthouse’s user can be prompted to install the web app test.
    - Lighthouse tests currently are only available for mobile pages. To control the install experience,
    - 0.82% of all desktop and 0.94% of all mobile pages use the OnBeforeInstallPrompt interface. + Lighthouse checks whether a page is eligble for an install prompt
    + though it currently is only available for mobile pages. Looking at Lighthouse data in the HTTP Archive, 1.56% of mobile pages have an
    + installable manifest. Readers may notice this is higher than the 0.37% of mobile pages that
    + register a service worker, which is also a requirement of the install prompt
    + (issue raised to make this clearer in the documentation).
    + The difference in these numbers may be due to Service Workers being registered on pages other than the home page as the Web Almanac only is restricted just to home pages. +

    +

    + To control the install experience, 0.82% of all desktop and 0.94% of all mobile pages use the OnBeforeInstallPrompt interface. At present support is limited to Chromium based browsers.

    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.
      • +
    • 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 we could find in the HTTP Archive.
    @@ -193,8 +189,8 @@

    Web App Manifest Properties

    Google Cloud Messaging (GCM) service. Interestingly there’re almost no differences between mobile
    and desktop. On both platforms, however, there’s a long tail of properties that are not interpreted
    by browsers but that contain potentially useful metadata like author or version. We also found
    - a non-trivial amount of mistyped properties, our favorite being shot_name. An interesting outlier
    - is the serviceworker property which is standard, but not implemented by any browser vendor —
    + a non-trivial amount of mistyped properties; our favorite being shot_name. An interesting outlier
    + is the serviceworker property, which is standard but not implemented by any browser vendor —
    nevertheless, it was found on 0.09% of all web app manifests used by mobile and desktop pages.

    <bar chart of 11_04 mobile>

    @@ -204,7 +200,7 @@

    Web App Manifest Properties

    Display Values

    Looking at the values developers set for the display property, it becomes immediately clear
    - that they want PWAs to be perceived as “proper” apps that don’t reveal their web technology origins.
    + that they want PWAs to be perceived as “proper” apps that don’t reveal their web technology origins.
    By choosing "standalone", they make sure no browser UI is shown to the end-user. This is reflected
    by the majority of apps that make use of the prefers_related_applications property: more that 97%
    of both mobile and desktop applications do not prefer native applications. @@ -216,7 +212,7 @@

    Display Values

    Category Values

    The categories member describes the expected application categories to which the web application belongs.
    - It is only meant as a hint to catalogs or stores listing web applications, and it is expected that
    + It is only meant as a hint to catalogs or app stores listing web applications, and it is expected that
    these will make a best effort to find appropriate categories (or category) under which to list the
    web application. There were not too many manifests that made use of the property, but it is
    interesting to see the shift from shopping being the most popular category on mobile to business,
    @@ -240,9 +236,10 @@

    Icon Sizes

    Figure 7b: Popular icon sizes on desktop.

    Orientation Values

    - The valid values for the orientation property are defined
    - in the Screen Orientation API specification. Namely there are "any", "natural", "landscape",
    - "portrait", "portrait-primary", "portrait-secondary", "landscape-primary", and "landscape-secondary".
    + The valid values for the orientation property are
    + defined in the Screen Orientation API specification.
    + Namely there are "any", "natural", "landscape", "portrait", "portrait-primary", "portrait-secondary",
    + "landscape-primary", and "landscape-secondary".
    Portrait orientation is the clear winner on both platforms, followed by any orientation.

    <11_04g mobile>

    @@ -251,10 +248,10 @@

    Orientation Values

    Figure 8b: Popular orientation values on desktop.

    Workbox

    - Workbox is a set of libraries that help with common service worker use cases. For instance, Workbox has tools
    - that can plug in to your build process and generate a manifest of files, which are then precached by your
    - service worker. Workbox includes libraries to handle runtime caching, request routing, cache expiration,
    - background sync, and more. + Workbox is a set of libraries that help with common service worker
    + use cases. For instance, Workbox has tools that can plug in to your build process and generate a manifest of files,
    + which are then precached by your service worker. Workbox includes libraries to handle runtime caching, request routing,
    + cache expiration, background sync, and more.

    Given the low-level nature of the service worker APIs, many developers have turned to Workbox as a way of
    @@ -267,6 +264,31 @@

    Workbox

    12.71% of them are using at least one of the Workbox libraries. This percentage is roughly consistent
    across desktop and mobile, with a slightly lower percentage (11.46%) on mobile compared to desktop (14.36%).

    +

    Conclusion

    +

    + The stats in this chapter show that PWAs are still only used by a small percentage of sites. However this relatively small usage
    + is driven by the more popular sites which have a much larger share of traffic, and pages beyond the home page may use this more:
    + we showed that 15% of page loads use a service workers. +

    +

    + PWAs have also often been seen as Google-driven technology and while the other browsers still have some way to go to catch up on
    + it's support it's positive to see support becoming more widespread. Maximiliano Firtman does a great
    + job of tracking this, including
    + explaining Safari PWA support
    + in light of poor documentation from Apple on that front. He (amongst others) also questions whether the tech giants really want
    + to support this technology. Apple doesn't use the term PWA much, and has explicitly stated that it does not want these apps listed in their App Store. Microsoft went the opposite direction not only
    + [encouraging PWAs in it's app store, but even automatically indexing any found when as it craweled the web]
    + (https://docs.microsoft.com/en-us/microsoft-edge/progressive-web-apps/microsoft-store), though with it moving on from the Windows
    + Phone platform the future of that is uncertain. Google has also
    + made moves to accepting PWAs in its app store
    + though Maxim questions
    + Android's commitment to the PWA compared to Chrome. +

    +

    + Even though progress on supporting PWAs is slower than we'd like, adoption is increasing. We may not quite have hit the point where
    + PWAs are mainstream yet but the advantages they give for performance and greater control over caching,
    + particualrly for mobile could soon lead to an explosion in use - perhaps 2020 is the year for this? +

    Authors

    From 3508637e4ed86b9477bfa8980c25562ba80d05c3 Mon Sep 17 00:00:00 2001 From: Barry Pollard Date: Thu, 31 Oct 2019 15:32:45 +0000 Subject: [PATCH 05/11] Update src/content/en/2019/pwa.md Co-Authored-By: Jeffrey Posnick --- src/content/en/2019/pwa.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/content/en/2019/pwa.md b/src/content/en/2019/pwa.md index 3335af5bab8..0ace7f5db03 100644 --- a/src/content/en/2019/pwa.md +++ b/src/content/en/2019/pwa.md @@ -186,7 +186,7 @@ additionally explicitly recommending 512×512, which doesn’t show as a particu The valid values for the `orientation` property are [defined in the Screen Orientation API specification](https://www.w3.org/TR/screen-orientation/#dom-orientationlocktype). -Namely there are `"any"`, `"natural"`, `"landscape"`, `"portrait"`, `"portrait-primary"`, `"portrait-secondary"`, +Currently, they are `"any"`, `"natural"`, `"landscape"`, `"portrait"`, `"portrait-primary"`, `"portrait-secondary"`, `"landscape-primary"`, and `"landscape-secondary"`. Portrait orientation is the clear winner on both platforms, followed by any orientation. From 66c4d68870aa9e158b4b20d02234b201fbf9d950 Mon Sep 17 00:00:00 2001 From: Barry Date: Thu, 31 Oct 2019 15:44:57 +0000 Subject: [PATCH 06/11] Update based on feedback from @jeffposnick --- src/content/en/2019/pwa.md | 36 ++++++++++++------------- src/templates/en/2019/chapters/pwa.html | 30 ++++++++++----------- 2 files changed, 31 insertions(+), 35 deletions(-) diff --git a/src/content/en/2019/pwa.md b/src/content/en/2019/pwa.md index 3335af5bab8..25b2ebfe18b 100644 --- a/src/content/en/2019/pwa.md +++ b/src/content/en/2019/pwa.md @@ -218,22 +218,20 @@ across desktop and mobile, with a slightly lower percentage (11.46%) on mobile c The stats in this chapter show that PWAs are still only used by a small percentage of sites. However this relatively small usage is driven by the more popular sites which have a much larger share of traffic, and pages beyond the home page may use this more: -we showed that 15% of page loads use a service workers. - -PWAs have also often been seen as Google-driven technology and while the other browsers still have some way to go to catch up on -it's support it's positive to see support becoming more widespread. [Maximiliano Firtman](https://twitter.com/firt) does a great -job of tracking this, including -[explaining Safari PWA support](https://medium.com/@firt/iphone-11-ipados-and-ios-13-for-pwas-and-web-development-5d5d9071cc49) -in light of poor documentation from Apple on that front. He (amongst others) also questions whether the tech giants really want -to support this technology. Apple doesn't use the term PWA much, and has [explicitly stated that it does not want these apps -listed in their App Store](https://developer.apple.com/news/?id=09062019b). Microsoft went the opposite direction not only -[encouraging PWAs in it's app store, but even automatically indexing any found when as it craweled the web] -(https://docs.microsoft.com/en-us/microsoft-edge/progressive-web-apps/microsoft-store), though with it moving on from the Windows - Phone platform the future of that is uncertain. Google has also - [made moves to accepting PWAs in its app store](https://medium.com/@firt/google-play-store-now-open-for-progressive-web-apps-ec6f3c6ff3cc) - though Maxim questions - [Android's commitment to the PWA compared to Chrome](https://medium.com/@firt/is-there-a-cold-war-between-android-and-chrome-because-of-pwas-e50a7471056c). - - Even though progress on supporting PWAs is slower than we'd like, adoption is increasing. We may not quite have hit the point where - PWAs are mainstream yet but the advantages they give for [performance](./performance) and greater control over [caching](./caching), - particualrly for [mobile](./mobile) could soon lead to an explosion in use - perhaps 2020 is the year for this? +we showed that 15% of page loads use a service workers. The advantages they give for [performance](./performance) and +greater control over [caching](./caching) particularly for [mobile](./mobile). + +PWAs have often been seen as Chrome-driven technology. Other browsers have made great strides recently to implement most of the +underlying technologies, although first-class installability lags on some platforms. it's positive to see support becoming more +widespread. [Maximiliano Firtman](https://twitter.com/firt) does a great job of tracking this, including +[explaining Safari PWA support](https://medium.com/@firt/iphone-11-ipados-and-ios-13-for-pwas-and-web-development-5d5d9071cc49). +Apple doesn't use the term PWA much, and has +[explicitly stated that these HTML5 apps are best delivered outside of the App Store](https://developer.apple.com/news/?id=09062019b). +Microsoft went the opposite direction not only [encouraging PWAs in it's app store, but even automatically indexing any found when +as it craweled the web] (https://docs.microsoft.com/en-us/microsoft-edge/progressive-web-apps/microsoft-store), though with it +moving on from the Windows Phone platform the future of that is uncertain. Google has also +[made moves to accepting PWAs in its app store](https://medium.com/@firt/google-play-store-now-open-for-progressive-web-apps-ec6f3c6ff3cc). + +PWAs provide a path forward for developers who would prefer to build and release on the web instead of on native platforms and app stores. +Not every operating system and browser offers full parity with native software, but improvements continue, and perhaps 2020 is the year +where we see an explosion in deployments? diff --git a/src/templates/en/2019/chapters/pwa.html b/src/templates/en/2019/chapters/pwa.html index c9a662ba0a3..8f07b83cd7b 100644 --- a/src/templates/en/2019/chapters/pwa.html +++ b/src/templates/en/2019/chapters/pwa.html @@ -268,26 +268,24 @@

    Conclusion

    The stats in this chapter show that PWAs are still only used by a small percentage of sites. However this relatively small usage
    is driven by the more popular sites which have a much larger share of traffic, and pages beyond the home page may use this more:
    - we showed that 15% of page loads use a service workers. + we showed that 15% of page loads use a service workers. The advantages they give for performance and
    + greater control over caching particularly for mobile.

    - PWAs have also often been seen as Google-driven technology and while the other browsers still have some way to go to catch up on
    - it's support it's positive to see support becoming more widespread. Maximiliano Firtman does a great
    - job of tracking this, including
    - explaining Safari PWA support
    - in light of poor documentation from Apple on that front. He (amongst others) also questions whether the tech giants really want
    - to support this technology. Apple doesn't use the term PWA much, and has explicitly stated that it does not want these apps listed in their App Store. Microsoft went the opposite direction not only
    - [encouraging PWAs in it's app store, but even automatically indexing any found when as it craweled the web]
    - (https://docs.microsoft.com/en-us/microsoft-edge/progressive-web-apps/microsoft-store), though with it moving on from the Windows
    - Phone platform the future of that is uncertain. Google has also
    - made moves to accepting PWAs in its app store
    - though Maxim questions
    - Android's commitment to the PWA compared to Chrome. + PWAs have often been seen as Chrome-driven technology. Other browsers have made great strides recently to implement most of the
    + underlying technologies, although first-class installability lags on some platforms. it's positive to see support becoming more
    + widespread. Maximiliano Firtman does a great job of tracking this, including
    + explaining Safari PWA support.
    + Apple doesn't use the term PWA much, and has
    + explicitly stated that these HTML5 apps are best delivered outside of the App Store.
    + Microsoft went the opposite direction not only encouraging PWAs in it's app store, but even automatically indexing any found when as it craweled the web, though with it
    + moving on from the Windows Phone platform the future of that is uncertain. Google has also
    + made moves to accepting PWAs in its app store.

    - Even though progress on supporting PWAs is slower than we'd like, adoption is increasing. We may not quite have hit the point where
    - PWAs are mainstream yet but the advantages they give for performance and greater control over caching,
    - particualrly for mobile could soon lead to an explosion in use - perhaps 2020 is the year for this? + PWAs provide a path forward for developers who would prefer to build and release on the web instead of on native platforms and app stores.
    + Not every operating system and browser offers full parity with native software, but improvements continue, and perhaps 2020 is the year
    + where we see an explosion in deployments?

    From 79756fa6bc5057cf7cc007f265dd1fed2b6ff715 Mon Sep 17 00:00:00 2001 From: Barry Pollard Date: Thu, 31 Oct 2019 20:28:34 +0000 Subject: [PATCH 07/11] Update src/templates/en/2019/chapters/pwa.html Co-Authored-By: Jeffrey Posnick --- src/templates/en/2019/chapters/pwa.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/templates/en/2019/chapters/pwa.html b/src/templates/en/2019/chapters/pwa.html index 8f07b83cd7b..c2ebe21d468 100644 --- a/src/templates/en/2019/chapters/pwa.html +++ b/src/templates/en/2019/chapters/pwa.html @@ -283,7 +283,7 @@

    Conclusion

    made moves to accepting PWAs in its app store.

    - PWAs provide a path forward for developers who would prefer to build and release on the web instead of on native platforms and app stores.
    + PWAs provide a path forward for developers who would prefer to build and release on the web instead of on native platforms.
    Not every operating system and browser offers full parity with native software, but improvements continue, and perhaps 2020 is the year
    where we see an explosion in deployments?

    From 307762e9f88b1c5ad092913eb08c845ec97609e0 Mon Sep 17 00:00:00 2001 From: Barry Pollard Date: Thu, 31 Oct 2019 20:28:57 +0000 Subject: [PATCH 08/11] Update src/templates/en/2019/chapters/pwa.html Co-Authored-By: Jeffrey Posnick --- src/templates/en/2019/chapters/pwa.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/templates/en/2019/chapters/pwa.html b/src/templates/en/2019/chapters/pwa.html index c2ebe21d468..d30718af917 100644 --- a/src/templates/en/2019/chapters/pwa.html +++ b/src/templates/en/2019/chapters/pwa.html @@ -278,7 +278,7 @@

    Conclusion

    explaining Safari PWA support.
    Apple doesn't use the term PWA much, and has
    explicitly stated that these HTML5 apps are best delivered outside of the App Store.
    - Microsoft went the opposite direction not only encouraging PWAs in it's app store, but even automatically indexing any found when as it craweled the web, though with it
    + Microsoft went the opposite direction, not only encouraging PWAs in its app store, but even automatically indexing any found when as it crawled the web. moving on from the Windows Phone platform the future of that is uncertain. Google has also
    made moves to accepting PWAs in its app store.

    From a1857af35df6a0958d3ffae05f41d7767dd3528d Mon Sep 17 00:00:00 2001 From: Barry Pollard Date: Thu, 31 Oct 2019 20:29:05 +0000 Subject: [PATCH 09/11] Update src/templates/en/2019/chapters/pwa.html Co-Authored-By: Jeffrey Posnick --- src/templates/en/2019/chapters/pwa.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/templates/en/2019/chapters/pwa.html b/src/templates/en/2019/chapters/pwa.html index d30718af917..8e5d1fd776c 100644 --- a/src/templates/en/2019/chapters/pwa.html +++ b/src/templates/en/2019/chapters/pwa.html @@ -279,7 +279,7 @@

    Conclusion

    Apple doesn't use the term PWA much, and has
    explicitly stated that these HTML5 apps are best delivered outside of the App Store.
    Microsoft went the opposite direction, not only encouraging PWAs in its app store, but even automatically indexing any found when as it crawled the web. - moving on from the Windows Phone platform the future of that is uncertain. Google has also
    +Google has also
    made moves to accepting PWAs in its app store.

    From 15b52d92e25d3b0a6f4dcac7cc90d216f122429e Mon Sep 17 00:00:00 2001 From: Barry Pollard Date: Thu, 31 Oct 2019 20:29:15 +0000 Subject: [PATCH 10/11] Update src/templates/en/2019/chapters/pwa.html Co-Authored-By: Jeffrey Posnick --- src/templates/en/2019/chapters/pwa.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/templates/en/2019/chapters/pwa.html b/src/templates/en/2019/chapters/pwa.html index 8e5d1fd776c..2522a734da5 100644 --- a/src/templates/en/2019/chapters/pwa.html +++ b/src/templates/en/2019/chapters/pwa.html @@ -280,7 +280,7 @@

    Conclusion

    explicitly stated that these HTML5 apps are best delivered outside of the App Store.
    Microsoft went the opposite direction, not only encouraging PWAs in its app store, but even automatically indexing any found when as it crawled the web. Google has also
    - made moves to accepting PWAs in its app store. +provided a method for listing web apps in the Google Play Store, via Trusted Web Activities.

    PWAs provide a path forward for developers who would prefer to build and release on the web instead of on native platforms.
    From cc62e5e9ae50dfab73f16ed4a23e8c30dfcaca52 Mon Sep 17 00:00:00 2001 From: Barry Date: Thu, 31 Oct 2019 20:58:40 +0000 Subject: [PATCH 11/11] Remove inter-paragraph line breaks to be consistent with other chapters and reduce chance of bugs --- src/content/en/2019/pwa.md | 167 +++++++------------- src/templates/en/2019/chapters/pwa.html | 195 +++++++----------------- 2 files changed, 107 insertions(+), 255 deletions(-) diff --git a/src/content/en/2019/pwa.md b/src/content/en/2019/pwa.md index a95a443dd49..282a10ca543 100644 --- a/src/content/en/2019/pwa.md +++ b/src/content/en/2019/pwa.md @@ -8,46 +8,21 @@ reviewers: [hyperpress, ahmadawais] ## Introduction -Progressive Web Apps (PWA) are a new class of web applications, building on top of platform primitives -like the [Service Worker APIs](https://developer.mozilla.org/en/docs/Web/API/Service_Worker_API). -Service workers allow apps to support network-independent loading by acting as a network proxy, -intercepting your web app's outgoing requests, and replying with programmatic or cached responses. -Service workers can receive push notifications and synchronize data in the background even when -the corresponding app is not running. Additional, service workers — together with -[Web App Manifests](https://developer.mozilla.org/en-US/docs/Web/Manifest) — -allow users to install PWAs to their devices’ home screens. - -Service workers were [first implemented in Chrome 40](https://blog.chromium.org/2014/12/chrome-40-beta-powerful-offline-and.html), -back in December 2014, and the term Progressive Web Apps was -[coined by Frances Berriman and Alex Russell](https://infrequently.org/2015/06/progressive-apps-escaping-tabs-without-losing-our-soul/) -in 2015. As service workers are now finally [implemented in all major browsers](https://jakearchibald.github.io/isserviceworkerready/), -we were wondering how many PWAs are actually out there, and how do they make use of these new technologies? -Certain advanced APIs like [Background Sync](https://developers.google.com/web/updates/2015/12/background-sync) -are currently still [only available on Chromium-based browsers](https://caniuse.com/#feat=background-sync), -so as an additional question, we looked into which features these PWAs actually use. +Progressive Web Apps (PWA) are a new class of web applications, building on top of platform primitives like the [Service Worker APIs](https://developer.mozilla.org/en/docs/Web/API/Service_Worker_API). Service workers allow apps to support network-independent loading by acting as a network proxy, intercepting your web app's outgoing requests, and replying with programmatic or cached responses. Service workers can receive push notifications and synchronize data in the background even when the corresponding app is not running. Additional, service workers — together with [Web App Manifests](https://developer.mozilla.org/en-US/docs/Web/Manifest) — allow users to install PWAs to their devices’ home screens. + +Service workers were [first implemented in Chrome 40](https://blog.chromium.org/2014/12/chrome-40-beta-powerful-offline-and.html), back in December 2014, and the term Progressive Web Apps was [coined by Frances Berriman and Alex Russell](https://infrequently.org/2015/06/progressive-apps-escaping-tabs-without-losing-our-soul/) in 2015. As service workers are now finally [implemented in all major browsers](https://jakearchibald.github.io/isserviceworkerready/), we were wondering how many PWAs are actually out there, and how do they make use of these new technologies? Certain advanced APIs like [Background Sync](https://developers.google.com/web/updates/2015/12/background-sync) are currently still [only available on Chromium-based browsers](https://caniuse.com/#feat=background-sync), so as an additional question, we looked into which features these PWAs actually use. ## Service Workers ### Service Worker Registrations and Installability -The first metric we explore are service worker installations. Looking at the data exposed through -feature counters in the HTTP Archive, we find that 0.44% of all desktop and 0.37% of all mobile pages -register a service worker, and both curves over time are steeply growing. Now this might not look overly -impressive, but taking traffic data from Chrome Platform Status into account, we can see that about -[a service worker controlled 15% of all page loads](https://www.chromestatus.com/metrics/feature/timeline/popularity/990), -which can be interpreted as popular, high-traffic sites increasingly having started to embrace service workers. +The first metric we explore are service worker installations. Looking at the data exposed through feature counters in the HTTP Archive, we find that 0.44% of all desktop and 0.37% of all mobile pages register a service worker, and both curves over time are steeply growing. Now this might not look overly impressive, but taking traffic data from Chrome Platform Status into account, we can see that about [a service worker controlled 15% of all page loads](https://www.chromestatus.com/metrics/feature/timeline/popularity/990), which can be interpreted as popular, high-traffic sites increasingly having started to embrace service workers. `````` **Figure 1:** Service Worker installation over time for desktop and mobile -Lighthouse checks whether a page is eligble for an [install prompt](https://developers.google.com/web/tools/lighthouse/audits/install-prompt) -though it currently is only available for mobile pages. Looking at Lighthouse data in the HTTP Archive, 1.56% of mobile pages have an -[installable manifest](https://web.dev/installable-manifest/). Readers may notice this is higher than the 0.37% of mobile pages that -register a service worker, which is also a requirement of the install prompt -([issue raised to make this clearer in the documentation](https://github.com/GoogleChrome/web.dev/issues/1797)). -The difference in these numbers may be due to Service Workers being registered on pages other than the home page as the [Web Almanac -only is restricted just to home pages](./methodology). +Lighthouse checks whether a page is eligble for an [install prompt](https://developers.google.com/web/tools/lighthouse/audits/install-prompt) though it currently is only available for mobile pages. Looking at Lighthouse data in the HTTP Archive, 1.56% of mobile pages have an [installable manifest](https://web.dev/installable-manifest/). Readers may notice this is higher than the 0.37% of mobile pages that register a service worker, which is also a requirement of the install prompt ([issue raised to make this clearer in the documentation](https://github.com/GoogleChrome/web.dev/issues/1797)). The difference in these numbers may be due to Service Workers being registered on pages other than the home page as the [Web Almanac only is restricted just to home pages](./methodology). To control the install experience, 0.82% of all desktop and 0.94% of all mobile pages use the [`OnBeforeInstallPrompt` interface](https://w3c.github.io/manifest/#beforeinstallpromptevent-interface). At present [support is limited to Chromium based browsers](https://caniuse.com/#feat=web-app-manifest). @@ -64,12 +39,7 @@ In a service worker one can [listen for a number of events](https://developers.g - `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 we could find in the HTTP Archive. -The results for mobile and desktop are very similar with `fetch`, `install`, and `activate` being the three -most popular events, followed by `notificationclick` and `push`. 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 the moment. +We have examined which of these events are being listened to by service workers we could find in the HTTP Archive. The results for mobile and desktop are very similar with `fetch`, `install`, and `activate` being the three most popular events, followed by `notificationclick` and `push`. 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 the moment. `````` @@ -81,13 +51,7 @@ play a significant role at the moment. ### Service Worker File Sizes -File size or lines of code are in general a bad proxy for the complexity of the task at hand. -In this case, however, it is definitely interesting to compare (compressed) file sizes of service workers -for mobile and desktop. The median service worker file on desktop is 895 bytes, whereas on mobile it’s 694 bytes. -Throughout all percentiles desktop service workers are larger than mobile service workers. -We note that these stats don’t account for dynamically imported scripts through the -[`importScripts()`](https://developer.mozilla.org/en-US/docs/Web/API/WorkerGlobalScope/importScripts) method, -which likely skews the results higher. +File size or lines of code are in general a bad proxy for the complexity of the task at hand. In this case, however, it is definitely interesting to compare (compressed) file sizes of service workers for mobile and desktop. The median service worker file on desktop is 895 bytes, whereas on mobile it’s 694 bytes. Throughout all percentiles desktop service workers are larger than mobile service workers. We note that these stats don’t account for dynamically imported scripts through the [`importScripts()`](https://developer.mozilla.org/en-US/docs/Web/API/WorkerGlobalScope/importScripts) method, which likely skews the results higher. `````` @@ -101,29 +65,29 @@ which likely skews the results higher. ### Web App Manifest Properties -The web app manifest is a simple JSON file that tells the browser about a web application -and how it should behave when installed on the user's mobile device or desktop. A typical -manifest file includes information about the app name, icons it should use, the start URL -it should open at when launched, and more. Only 1.54% of all encountered manifests were -invalid JSON, and the rest parsed correctly. - -We looked at the different properties defined by the -[specification](https://w3c.github.io/manifest/#webappmanifest-dictionary), -and also considered non-standard proprietary properties. According to the Web App Manifest spec, -the following properties are allowed: `dir`, `lang`, `name`, `short_name`, `description`, -`icons`, `screenshots`, `categories`, `iarc_rating_id`, `start_url`, `display`, `orientation`, -`theme_color`, `background_color`, `scope`, `serviceworker`, `related_applications`, and -`prefer_related_applications`. The only property that we didn’t observe in the wild was -`iarc_rating_id`, which is a string that represents the International Age Rating Coalition (IARC) -certification code of the web application. It is intended to be used to determine which ages -the web application is appropriate for. The proprietary properties we encountered still -frequently were `gcm_sender_id` and `gcm_user_visible_only` from the legacy -Google Cloud Messaging (GCM) service. Interestingly there’re almost no differences between mobile -and desktop. On both platforms, however, there’s a long tail of properties that are not interpreted -by browsers but that contain potentially useful metadata like `author` or `version`. We also found -a non-trivial amount of mistyped properties; our favorite being `shot_name`. An interesting outlier -is the `serviceworker` property, which is standard but not implemented by any browser vendor — -nevertheless, it was found on 0.09% of all web app manifests used by mobile and desktop pages. +The web app manifest is a simple JSON file that tells the browser about a web application and how it should behave when installed on the user's mobile device or desktop. A typical +manifest file includes information about the app name, icons it should use, the start URL it should open at when launched, and more. Only 1.54% of all encountered manifests were invalid JSON, and the rest parsed correctly. + +We looked at the different properties defined by the [specification](https://w3c.github.io/manifest/#webappmanifest-dictionary), and also considered non-standard proprietary properties. According to the Web App Manifest spec, the following properties are allowed: +- `dir` +- `lang` +- `name` +- `short_name` +- `description` +- `icons` +- `screenshots` +- `categories` +- `iarc_rating_id` +- `start_url` +- `display` +- `orientation` +- `theme_color` +- `background_color` +- `scope` +- `serviceworker` +- `related_applications` +- `prefer_related_applications` +The only property that we didn’t observe in the wild was `iarc_rating_id`, which is a string that represents the International Age Rating Coalition (IARC) certification code of the web application. It is intended to be used to determine which ages the web application is appropriate for. The proprietary properties we encountered still frequently were `gcm_sender_id` and `gcm_user_visible_only` from the legacy Google Cloud Messaging (GCM) service. Interestingly there’re almost no differences between mobile and desktop. On both platforms, however, there’s a long tail of properties that are not interpreted by browsers but that contain potentially useful metadata like `author` or `version`. We also found a non-trivial amount of mistyped properties; our favorite being `shot_name`. An interesting outlier is the `serviceworker` property, which is standard but not implemented by any browser vendor — nevertheless, it was found on 0.09% of all web app manifests used by mobile and desktop pages. `````` @@ -135,11 +99,7 @@ nevertheless, it was found on 0.09% of all web app manifests used by mobile and ### Display Values -Looking at the values developers set for the `display` property, it becomes immediately clear -that they want PWAs to be perceived as “proper” apps that don’t reveal their web technology origins. -By choosing `"standalone"`, they make sure no browser UI is shown to the end-user. This is reflected -by the majority of apps that make use of the `prefers_related_applications` property: more that 97% -of both mobile and desktop applications do *not* prefer native applications. +Looking at the values developers set for the `display` property, it becomes immediately clear that they want PWAs to be perceived as “proper” apps that don’t reveal their web technology origins. By choosing `"standalone"`, they make sure no browser UI is shown to the end-user. This is reflected by the majority of apps that make use of the `prefers_related_applications` property: more that 97% of both mobile and desktop applications do *not* prefer native applications. ```<11_04c mobile>``` @@ -151,12 +111,7 @@ of both mobile and desktop applications do *not* prefer native applications. ### Category Values -The `categories` member describes the expected application categories to which the web application belongs. -It is only meant as a hint to catalogs or app stores listing web applications, and it is expected that -these will make a best effort to find appropriate categories (or category) under which to list the -web application. There were not too many manifests that made use of the property, but it is -interesting to see the shift from *shopping* being the most popular category on mobile to *business*, -*technology*, and *web* (whatever may be meant with that) on desktop that share the first place evenly. +The `categories` member describes the expected application categories to which the web application belongs. It is only meant as a hint to catalogs or app stores listing web applications, and it is expected that these will make a best effort to find appropriate categories (or category) under which to list the web application. There were not too many manifests that made use of the property, but it is interesting to see the shift from *shopping* being the most popular category on mobile to *business*, *technology*, and *web* (whatever may be meant with that) on desktop that share the first place evenly. ```<11_04d mobile>``` @@ -168,11 +123,7 @@ interesting to see the shift from *shopping* being the most popular category on ### Icon Sizes -Lighthouse [requires](https://developers.google.com/web/tools/lighthouse/audits/manifest-contains-192px-icon) -at least an icon sized 192×192, but common favicon generation tools create a plethora of other sizes, too. -Lighthouse’s rule is probably the culprit for 192×192 being the most popular choice of icon size on both -desktop and mobile, despite [Google’s documentation](https://developers.google.com/web/fundamentals/web-app-manifest#icons) -additionally explicitly recommending 512×512, which doesn’t show as a particularly prominent option. +Lighthouse [requires](https://developers.google.com/web/tools/lighthouse/audits/manifest-contains-192px-icon) at least an icon sized 192×192, but common favicon generation tools create a plethora of other sizes, too. Lighthouse’s rule is probably the culprit for 192×192 being the most popular choice of icon size on both desktop and mobile, despite [Google’s documentation](https://developers.google.com/web/fundamentals/web-app-manifest#icons) additionally explicitly recommending 512×512, which doesn’t show as a particularly prominent option. ```<11_04f mobile>``` @@ -184,10 +135,16 @@ additionally explicitly recommending 512×512, which doesn’t show as a particu ### Orientation Values -The valid values for the `orientation` property are -[defined in the Screen Orientation API specification](https://www.w3.org/TR/screen-orientation/#dom-orientationlocktype). -Currently, they are `"any"`, `"natural"`, `"landscape"`, `"portrait"`, `"portrait-primary"`, `"portrait-secondary"`, -`"landscape-primary"`, and `"landscape-secondary"`. +The valid values for the `orientation` property are [defined in the Screen Orientation API specification](https://www.w3.org/TR/screen-orientation/#dom-orientationlocktype). +Currently, they are: +- `"any"` +- `"natural"` +- `"landscape"` +- `"portrait"` +- `"portrait-primary"` +- `"portrait-secondary"` +- `"landscape-primary"` +- `"landscape-secondary"`. Portrait orientation is the clear winner on both platforms, followed by any orientation. ```<11_04g mobile>``` @@ -200,38 +157,16 @@ Portrait orientation is the clear winner on both platforms, followed by any orie ## Workbox -[Workbox](https://developers.google.com/web/tools/workbox) is a set of libraries that help with common service worker -use cases. For instance, Workbox has tools that can plug in to your build process and generate a manifest of files, -which are then precached by your service worker. Workbox includes libraries to handle runtime caching, request routing, -cache expiration, background sync, and more. +[Workbox](https://developers.google.com/web/tools/workbox) is a set of libraries that help with common service worker use cases. For instance, Workbox has tools that can plug in to your build process and generate a manifest of files, which are then precached by your service worker. Workbox includes libraries to handle runtime caching, request routing, cache expiration, background sync, and more. -Given the low-level nature of the service worker APIs, many developers have turned to Workbox as a way of -structuring their service worker logic into higher-level, reusable chunks of code. Workbox adoption is also -driven by its inclusion as a feature in a number of popular JavaScript framework starter kits, like -[`create-react-app`](https://create-react-app.dev/) and [Vue's PWA plugin](https://www.npmjs.com/package/@vue/cli-plugin-pwa). +Given the low-level nature of the service worker APIs, many developers have turned to Workbox as a way of structuring their service worker logic into higher-level, reusable chunks of code. Workbox adoption is also driven by its inclusion as a feature in a number of popular JavaScript framework starter kits, like [`create-react-app`](https://create-react-app.dev/) and [Vue's PWA plugin](https://www.npmjs.com/package/@vue/cli-plugin-pwa). -The HTTP Archive shows that, out of the total population of sites that register a service worker, -12.71% of them are using at least one of the Workbox libraries. This percentage is roughly consistent -across desktop and mobile, with a slightly lower percentage (11.46%) on mobile compared to desktop (14.36%). +The HTTP Archive shows that, out of the total population of sites that register a service worker, 12.71% of them are using at least one of the Workbox libraries. This percentage is roughly consistent across desktop and mobile, with a slightly lower percentage (11.46%) on mobile compared to desktop (14.36%). ## Conclusion -The stats in this chapter show that PWAs are still only used by a small percentage of sites. However this relatively small usage -is driven by the more popular sites which have a much larger share of traffic, and pages beyond the home page may use this more: -we showed that 15% of page loads use a service workers. The advantages they give for [performance](./performance) and -greater control over [caching](./caching) particularly for [mobile](./mobile). - -PWAs have often been seen as Chrome-driven technology. Other browsers have made great strides recently to implement most of the -underlying technologies, although first-class installability lags on some platforms. it's positive to see support becoming more -widespread. [Maximiliano Firtman](https://twitter.com/firt) does a great job of tracking this, including -[explaining Safari PWA support](https://medium.com/@firt/iphone-11-ipados-and-ios-13-for-pwas-and-web-development-5d5d9071cc49). -Apple doesn't use the term PWA much, and has -[explicitly stated that these HTML5 apps are best delivered outside of the App Store](https://developer.apple.com/news/?id=09062019b). -Microsoft went the opposite direction not only [encouraging PWAs in it's app store, but even automatically indexing any found when -as it craweled the web] (https://docs.microsoft.com/en-us/microsoft-edge/progressive-web-apps/microsoft-store), though with it -moving on from the Windows Phone platform the future of that is uncertain. Google has also -[made moves to accepting PWAs in its app store](https://medium.com/@firt/google-play-store-now-open-for-progressive-web-apps-ec6f3c6ff3cc). - -PWAs provide a path forward for developers who would prefer to build and release on the web instead of on native platforms and app stores. -Not every operating system and browser offers full parity with native software, but improvements continue, and perhaps 2020 is the year -where we see an explosion in deployments? +The stats in this chapter show that PWAs are still only used by a small percentage of sites. However this relatively small usage is driven by the more popular sites which have a much larger share of traffic, and pages beyond the home page may use this more: we showed that 15% of page loads use a service workers. The advantages they give for [performance](./performance) and greater control over [caching](./caching) particularly for [mobile](./mobile) should mean that usage will continue to grow. + +PWAs have often been seen as Chrome-driven technology. Other browsers have made great strides recently to implement most of the underlying technologies, although first-class installability lags on some platforms. it's positive to see support becoming more widespread. [Maximiliano Firtman](https://twitter.com/firt) does a great job of tracking this, including [explaining Safari PWA support](https://medium.com/@firt/iphone-11-ipados-and-ios-13-for-pwas-and-web-development-5d5d9071cc49). Apple doesn't use the term PWA much, and has [explicitly stated that these HTML5 apps are best delivered outside of the App Store](https://developer.apple.com/news/?id=09062019b). Microsoft went the opposite direction, not only [encouraging PWAs in its app store, but even automatically indexing any found when as it crawled the web](https://docs.microsoft.com/en-us/microsoft-edge/progressive-web-apps/microsoft-store). Google has also provided a method for listing web apps in the Google Play Store, via [Trusted Web Activities](https://developers.google.com/web/updates/2019/02/using-twa>). + +PWAs provide a path forward for developers who would prefer to build and release on the web instead of on native platforms and app stores. Not every operating system and browser offers full parity with native software, but improvements continue, and perhaps 2020 is the year where we see an explosion in deployments? diff --git a/src/templates/en/2019/chapters/pwa.html b/src/templates/en/2019/chapters/pwa.html index 2522a734da5..c813f76d9e9 100644 --- a/src/templates/en/2019/chapters/pwa.html +++ b/src/templates/en/2019/chapters/pwa.html @@ -84,46 +84,14 @@

    {{ render_byline() }}

    Introduction

    -

    - Progressive Web Apps (PWA) are a new class of web applications, building on top of platform primitives
    - like the Service Worker APIs.
    - Service workers allow apps to support network-independent loading by acting as a network proxy,
    - intercepting your web app's outgoing requests, and replying with programmatic or cached responses.
    - Service workers can receive push notifications and synchronize data in the background even when
    - the corresponding app is not running. Additional, service workers — together with
    - Web App Manifests —
    - allow users to install PWAs to their devices’ home screens. -

    -

    - Service workers were first implemented in Chrome 40,
    - back in December 2014, and the term Progressive Web Apps was
    - coined by Frances Berriman and Alex Russell
    - in 2015. As service workers are now finally implemented in all major browsers,
    - we were wondering how many PWAs are actually out there, and how do they make use of these new technologies?
    - Certain advanced APIs like Background Sync
    - are currently still only available on Chromium-based browsers,
    - so as an additional question, we looked into which features these PWAs actually use. -

    +

    Progressive Web Apps (PWA) are a new class of web applications, building on top of platform primitives like the Service Worker APIs. Service workers allow apps to support network-independent loading by acting as a network proxy, intercepting your web app's outgoing requests, and replying with programmatic or cached responses. Service workers can receive push notifications and synchronize data in the background even when the corresponding app is not running. Additional, service workers — together with Web App Manifests — allow users to install PWAs to their devices’ home screens.

    +

    Service workers were first implemented in Chrome 40, back in December 2014, and the term Progressive Web Apps was coined by Frances Berriman and Alex Russell in 2015. As service workers are now finally implemented in all major browsers, we were wondering how many PWAs are actually out there, and how do they make use of these new technologies? Certain advanced APIs like Background Sync are currently still only available on Chromium-based browsers, so as an additional question, we looked into which features these PWAs actually use.

    Service Workers

    Service Worker Registrations and Installability

    -

    - The first metric we explore are service worker installations. Looking at the data exposed through
    - feature counters in the HTTP Archive, we find that 0.44% of all desktop and 0.37% of all mobile pages
    - register a service worker, and both curves over time are steeply growing. Now this might not look overly
    - impressive, but taking traffic data from Chrome Platform Status into account, we can see that about
    - a service worker controlled 15% of all page loads,
    - which can be interpreted as popular, high-traffic sites increasingly having started to embrace service workers. -

    +

    The first metric we explore are service worker installations. Looking at the data exposed through feature counters in the HTTP Archive, we find that 0.44% of all desktop and 0.37% of all mobile pages register a service worker, and both curves over time are steeply growing. Now this might not look overly impressive, but taking traffic data from Chrome Platform Status into account, we can see that about a service worker controlled 15% of all page loads, which can be interpreted as popular, high-traffic sites increasingly having started to embrace service workers.

    <timeseries chart of 11_01b>

    Figure 1: Service Worker installation over time for desktop and mobile

    -

    - Lighthouse checks whether a page is eligble for an install prompt
    - though it currently is only available for mobile pages. Looking at Lighthouse data in the HTTP Archive, 1.56% of mobile pages have an
    - installable manifest. Readers may notice this is higher than the 0.37% of mobile pages that
    - register a service worker, which is also a requirement of the install prompt
    - (issue raised to make this clearer in the documentation).
    - The difference in these numbers may be due to Service Workers being registered on pages other than the home page as the Web Almanac only is restricted just to home pages. -

    +

    Lighthouse checks whether a page is eligble for an install prompt though it currently is only available for mobile pages. Looking at Lighthouse data in the HTTP Archive, 1.56% of mobile pages have an installable manifest. Readers may notice this is higher than the 0.37% of mobile pages that register a service worker, which is also a requirement of the install prompt (issue raised to make this clearer in the documentation). The difference in these numbers may be due to Service Workers being registered on pages other than the home page as the Web Almanac only is restricted just to home pages.

    To control the install experience, 0.82% of all desktop and 0.94% of all mobile pages use the OnBeforeInstallPrompt interface. At present support is limited to Chromium based browsers.

    @@ -139,27 +107,14 @@

    Service Worker Events

  • 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 we could find in the HTTP Archive.
    - The results for mobile and desktop are very similar with fetch, install, and activate being the three
    - most popular events, followed by notificationclick and push. 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 the moment. -

    +

    We have examined which of these events are being listened to by service workers we could find in the HTTP Archive. The results for mobile and desktop are very similar with fetch, install, and activate being the three most popular events, followed by notificationclick and push. 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 the moment.

    <bar chart of 11_03 mobile>

    Figure 2a: Service worker events on mobile, ordered by decreasing frequency.

    <bar chart of 11_03 desktop>

    Figure 2b: Service worker events on desktop, ordered by decreasing frequency.

    Service Worker File Sizes

    - File size or lines of code are in general a bad proxy for the complexity of the task at hand.
    - In this case, however, it is definitely interesting to compare (compressed) file sizes of service workers
    - for mobile and desktop. The median service worker file on desktop is 895 bytes, whereas on mobile it’s 694 bytes.
    - Throughout all percentiles desktop service workers are larger than mobile service workers.
    - We note that these stats don’t account for dynamically imported scripts through the
    - importScripts() method,
    - which likely skews the results higher. + File size or lines of code are in general a bad proxy for the complexity of the task at hand. In this case, however, it is definitely interesting to compare (compressed) file sizes of service workers for mobile and desktop. The median service worker file on desktop is 895 bytes, whereas on mobile it’s 694 bytes. Throughout all percentiles desktop service workers are larger than mobile service workers. We note that these stats don’t account for dynamically imported scripts through the importScripts() method, which likely skews the results higher.

    <distribution of 11_03b mobile>

    Figure 3a: Percentiles of service worker file sizes on mobile.

    @@ -168,125 +123,87 @@

    Service Worker File Sizes

    Web App Manifests

    Web App Manifest Properties

    - The web app manifest is a simple JSON file that tells the browser about a web application
    - and how it should behave when installed on the user's mobile device or desktop. A typical
    - manifest file includes information about the app name, icons it should use, the start URL
    - it should open at when launched, and more. Only 1.54% of all encountered manifests were
    - invalid JSON, and the rest parsed correctly. -

    -

    - We looked at the different properties defined by the
    - specification,
    - and also considered non-standard proprietary properties. According to the Web App Manifest spec,
    - the following properties are allowed: dir, lang, name, short_name, description,
    - icons, screenshots, categories, iarc_rating_id, start_url, display, orientation,
    - theme_color, background_color, scope, serviceworker, related_applications, and
    - prefer_related_applications. The only property that we didn’t observe in the wild was
    - iarc_rating_id, which is a string that represents the International Age Rating Coalition (IARC)
    - certification code of the web application. It is intended to be used to determine which ages
    - the web application is appropriate for. The proprietary properties we encountered still
    - frequently were gcm_sender_id and gcm_user_visible_only from the legacy
    - Google Cloud Messaging (GCM) service. Interestingly there’re almost no differences between mobile
    - and desktop. On both platforms, however, there’s a long tail of properties that are not interpreted
    - by browsers but that contain potentially useful metadata like author or version. We also found
    - a non-trivial amount of mistyped properties; our favorite being shot_name. An interesting outlier
    - is the serviceworker property, which is standard but not implemented by any browser vendor —
    - nevertheless, it was found on 0.09% of all web app manifests used by mobile and desktop pages. + The web app manifest is a simple JSON file that tells the browser about a web application and how it should behave when installed on the user's mobile device or desktop. A typical
    + manifest file includes information about the app name, icons it should use, the start URL it should open at when launched, and more. Only 1.54% of all encountered manifests were invalid JSON, and the rest parsed correctly.

    +

    We looked at the different properties defined by the specification, and also considered non-standard proprietary properties. According to the Web App Manifest spec, the following properties are allowed:

    +
      +
    • dir
      • +
    • lang
      • +
    • name
      • +
    • short_name
      • +
    • description
      • +
    • icons
      • +
    • screenshots
      • +
    • categories
      • +
    • iarc_rating_id
      • +
    • start_url
      • +
    • display
      • +
    • orientation
      • +
    • theme_color
      • +
    • background_color
      • +
    • scope
      • +
    • serviceworker
      • +
    • related_applications
      • +
    • + prefer_related_applications
      + The only property that we didn’t observe in the wild was iarc_rating_id, which is a string that represents the International Age Rating Coalition (IARC) certification code of the web application. It is intended to be used to determine which ages the web application is appropriate for. The proprietary properties we encountered still frequently were gcm_sender_id and gcm_user_visible_only from the legacy Google Cloud Messaging (GCM) service. Interestingly there’re almost no differences between mobile and desktop. On both platforms, however, there’s a long tail of properties that are not interpreted by browsers but that contain potentially useful metadata like author or version. We also found a non-trivial amount of mistyped properties; our favorite being shot_name. An interesting outlier is the serviceworker property, which is standard but not implemented by any browser vendor — nevertheless, it was found on 0.09% of all web app manifests used by mobile and desktop pages. +
      • +

    <bar chart of 11_04 mobile>

    Figure 4a: Web App Manifest properties ordered by decreasing popularity on mobile.

    <bar chart of 11_04 mobile>

    Figure 4b: Web App Manifest properties ordered by decreasing popularity on desktop.

    Display Values

    -

    - Looking at the values developers set for the display property, it becomes immediately clear
    - that they want PWAs to be perceived as “proper” apps that don’t reveal their web technology origins.
    - By choosing "standalone", they make sure no browser UI is shown to the end-user. This is reflected
    - by the majority of apps that make use of the prefers_related_applications property: more that 97%
    - of both mobile and desktop applications do not prefer native applications. -

    +

    Looking at the values developers set for the display property, it becomes immediately clear that they want PWAs to be perceived as “proper” apps that don’t reveal their web technology origins. By choosing "standalone", they make sure no browser UI is shown to the end-user. This is reflected by the majority of apps that make use of the prefers_related_applications property: more that 97% of both mobile and desktop applications do not prefer native applications.

    <11_04c mobile>

    Figure 5a: Values for the display property on mobile.

    <11_04c desktop>

    Figure 5b: Values for the display property on desktop.

    Category Values

    -

    - The categories member describes the expected application categories to which the web application belongs.
    - It is only meant as a hint to catalogs or app stores listing web applications, and it is expected that
    - these will make a best effort to find appropriate categories (or category) under which to list the
    - web application. There were not too many manifests that made use of the property, but it is
    - interesting to see the shift from shopping being the most popular category on mobile to business,
    - technology, and web (whatever may be meant with that) on desktop that share the first place evenly. -

    +

    The categories member describes the expected application categories to which the web application belongs. It is only meant as a hint to catalogs or app stores listing web applications, and it is expected that these will make a best effort to find appropriate categories (or category) under which to list the web application. There were not too many manifests that made use of the property, but it is interesting to see the shift from shopping being the most popular category on mobile to business, technology, and web (whatever may be meant with that) on desktop that share the first place evenly.

    <11_04d mobile>

    Figure 6a: Values for the categories property on mobile.

    <11_04d desktop>

    Figure 6b: Values for the categories property on desktop.

    Icon Sizes

    -

    - Lighthouse requires
    - at least an icon sized 192×192, but common favicon generation tools create a plethora of other sizes, too.
    - Lighthouse’s rule is probably the culprit for 192×192 being the most popular choice of icon size on both
    - desktop and mobile, despite Google’s documentation
    - additionally explicitly recommending 512×512, which doesn’t show as a particularly prominent option. -

    +

    Lighthouse requires at least an icon sized 192×192, but common favicon generation tools create a plethora of other sizes, too. Lighthouse’s rule is probably the culprit for 192×192 being the most popular choice of icon size on both desktop and mobile, despite Google’s documentation additionally explicitly recommending 512×512, which doesn’t show as a particularly prominent option.

    <11_04f mobile>

    Figure 7a: Popular icon sizes on mobile.

    <11_04f desktop>

    Figure 7b: Popular icon sizes on desktop.

    Orientation Values

    - The valid values for the orientation property are
    - defined in the Screen Orientation API specification.
    - Namely there are "any", "natural", "landscape", "portrait", "portrait-primary", "portrait-secondary",
    - "landscape-primary", and "landscape-secondary".
    - Portrait orientation is the clear winner on both platforms, followed by any orientation. + 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".
      + Portrait orientation is the clear winner on both platforms, followed by any orientation. +
      • +

    <11_04g mobile>

    Figure 8a: Popular orientation values on mobile.

    <11_04g desktop>

    Figure 8b: Popular orientation values on desktop.

    Workbox

    +

    Workbox is a set of libraries that help with common service worker use cases. For instance, Workbox has tools that can plug in to your build process and generate a manifest of files, which are then precached by your service worker. Workbox includes libraries to handle runtime caching, request routing, cache expiration, background sync, and more.

    - Workbox is a set of libraries that help with common service worker
    - use cases. For instance, Workbox has tools that can plug in to your build process and generate a manifest of files,
    - which are then precached by your service worker. Workbox includes libraries to handle runtime caching, request routing,
    - cache expiration, background sync, and more. -

    -

    - Given the low-level nature of the service worker APIs, many developers have turned to Workbox as a way of
    - structuring their service worker logic into higher-level, reusable chunks of code. Workbox adoption is also
    - driven by its inclusion as a feature in a number of popular JavaScript framework starter kits, like
    - create-react-app and Vue's PWA plugin. -

    -

    - The HTTP Archive shows that, out of the total population of sites that register a service worker,
    - 12.71% of them are using at least one of the Workbox libraries. This percentage is roughly consistent
    - across desktop and mobile, with a slightly lower percentage (11.46%) on mobile compared to desktop (14.36%). + Given the low-level nature of the service worker APIs, many developers have turned to Workbox as a way of structuring their service worker logic into higher-level, reusable chunks of code. Workbox adoption is also driven by its inclusion as a feature in a number of popular JavaScript framework starter kits, like create-react-app and Vue's PWA plugin.

    +

    The HTTP Archive shows that, out of the total population of sites that register a service worker, 12.71% of them are using at least one of the Workbox libraries. This percentage is roughly consistent across desktop and mobile, with a slightly lower percentage (11.46%) on mobile compared to desktop (14.36%).

    Conclusion

    -

    - The stats in this chapter show that PWAs are still only used by a small percentage of sites. However this relatively small usage
    - is driven by the more popular sites which have a much larger share of traffic, and pages beyond the home page may use this more:
    - we showed that 15% of page loads use a service workers. The advantages they give for performance and
    - greater control over caching particularly for mobile. -

    -

    - PWAs have often been seen as Chrome-driven technology. Other browsers have made great strides recently to implement most of the
    - underlying technologies, although first-class installability lags on some platforms. it's positive to see support becoming more
    - widespread. Maximiliano Firtman does a great job of tracking this, including
    - explaining Safari PWA support.
    - Apple doesn't use the term PWA much, and has
    - explicitly stated that these HTML5 apps are best delivered outside of the App Store.
    - Microsoft went the opposite direction, not only encouraging PWAs in its app store, but even automatically indexing any found when as it crawled the web. -Google has also
    -provided a method for listing web apps in the Google Play Store, via Trusted Web Activities. -

    -

    - PWAs provide a path forward for developers who would prefer to build and release on the web instead of on native platforms.
    - Not every operating system and browser offers full parity with native software, but improvements continue, and perhaps 2020 is the year
    - where we see an explosion in deployments? -

    +

    The stats in this chapter show that PWAs are still only used by a small percentage of sites. However this relatively small usage is driven by the more popular sites which have a much larger share of traffic, and pages beyond the home page may use this more: we showed that 15% of page loads use a service workers. The advantages they give for performance and greater control over caching particularly for mobile should mean that usage will continue to grow.

    +

    PWAs have often been seen as Chrome-driven technology. Other browsers have made great strides recently to implement most of the underlying technologies, although first-class installability lags on some platforms. it's positive to see support becoming more widespread. Maximiliano Firtman does a great job of tracking this, including explaining Safari PWA support. Apple doesn't use the term PWA much, and has explicitly stated that these HTML5 apps are best delivered outside of the App Store. Microsoft went the opposite direction, not only encouraging PWAs in its app store, but even automatically indexing any found when as it crawled the web. Google has also provided a method for listing web apps in the Google Play Store, via Trusted Web Activities.

    +

    PWAs provide a path forward for developers who would prefer to build and release on the web instead of on native platforms and app stores. Not every operating system and browser offers full parity with native software, but improvements continue, and perhaps 2020 is the year where we see an explosion in deployments?

    Authors