Progressive Web Apps Roadshow (E-commerce Edition)

Firstly, a confession, I was due to attend the PWA Roadshow at Google’s London offices on March 1st 2018. But due to the trains from Chelmsford being in utter disarray due to a deluge of snow courtesy of a cold weather front known as “The Beast from the East”. I made the reluctant decision to recreate the experience in the comfort (and warmth) of my own home, sadly without Google’s awesome catering and other attendees! This was possible thanks to the talks being available on YouTube and the codelabs being available online too. So I can’t comment on what it was like to attend the day, as I wasn’t able to!

But what I was able to do was go through the talks at my own pace and take ample notes, the end result being this “live” blog capturing what I consider to be the most important points that were covered.

• The number of global users on mobile surpassed desktop in 2014 (source: comScore)
• Mobile users spend 13% of their time on the mobile web versus 87% in apps
• Users spend 78% of their time in their top 3 apps
• The average user installs zero apps per month
• Mobile users visit over 100 websites every month

What’s so great about native apps?

• They behave predictably
• They can be added to the home screen
• They start quickly
• They use push notifications to keep users returning
• They work offline
• They sync in the background
• They have access to device sensors such as the camera and microphone

What are the drawbacks of native apps?

• Limited reach, as a different version is needed for each device platform

Meanwhile, the Web Platform:

• Is safer
• Has a permissions model that is more respectful of user privacy
• Has far greater reach due to frictionless URLs

This is achieved in four key areas, PWAs should be:

• Fast - PWAs need to be fast as 53% of users abandon a website that doesn’t load within 3 seconds (source: DoubleClick, September 2016).
• Integrated - Users need to be able to add PWAs to their home screen and PWAs should integrate with the platform/browser through APIs such as the Media Playback API, Payment Request API and Media Session API.
• Reliable - PWAs should work offline and be able to handle poor connectivity.
• Engaging - PWAs should use push notifications to drive user engagement and web push to stay up-to-date.

Twitter has had great success with their own PWA, called Twitter Lite, which launched in the latter part of 2017. Twitter Lite now has more active users than any other Twitter client and beats all other Twitter clients in terms of smallest download size:

• iOS: 214MB!
• Android: 24MB
• PWA: 0.6MB

The Twitter Lite PWA was a great success delivering:

• 65% increase in page views per session
• 75% increase in Tweets sent

Other companies have had similar success with their own PWAs including: Air Berlin, The Weather Company, Lancôme, Lyft, OLX, Expedia, Air France, Tui, Trivago, Forbes, CNET, CNN, The Washington Post, The Guardian, The Financial Times, The Independent, Nikkei, Nivea, Rakuten, Alibaba, Pinterest, NBA and OLA Cabs to name a few.

PWAs are particularly important for emerging markets where native apps are:

• Costly to download
• Not always supported by older devices
• Suffer from slow performance on older hardware

66% of online purchases on mobile are on the web rather than native apps, but currently mobile conversion is a whopping 66% lower than on desktop devices. This is because checkout forms on mobile are:

• Very manual
• Tedious to complete
• Inconsistent from one site to another
• Slow

PWAs can change this dramatically by:

• Using autocomplete attributes, which generally make the checkout process 33% faster.
• Using the Payment Request API to eliminate checkout forms for users and standardise payment collection.

The Payment Request API allows developers to request payment information and more with a single API call that returns a JSON Payment Response object, which is then used to collect the payment. The Payment Request API is supported in Chrome with Microsoft and Firefox actively working on its implementation.

PWAs should work offline and be able to cope with poor connectivity.

60% of global mobile connections are 2G, so mobile experiences need to take into account slow or non-existent connectivity.

With a Service Worker the first request to a PWA along with the assets for that page come from the network as normal. The Service Worker only comes into effect with the second request (with one exception if you use skipWaiting(), which immediately activates the Service Worker).

Service Workers act as a proxy between the PWA and the network and enable developers to implement different caching strategies for each request within the app.  These caching strategies include:

• Cache first, fallback to the network - The Service Worker will attempt to retrieve the request response from its cache first before going to the network
• Network first, fallback to cache - The Service Worker will attempt to retrieve the request response from the network before falling back to the cache. This can be problematic for slow connections as it can take time for the network request to fail.
• Generic fallback - The Service Worker would try the cache first, then the network and then fallback to a generic cached response, such as “you are offline so we’re unable to retrieve that article right now, how about reading these articles:”, which would list articles from the user’s cache.
• Cache only - The Service Worker would only try the user’s cache for the request response.
• Network only - The Service Worker would only use the network for the request response.

Developers should browse the Material Design specification and iOS Human Interface Guidelines to increase familiarity with common user-interface components and their interactions.

Push notifications drive user engagement but can be a source of annoyance for users so require considered use, after all we are interrupting the user.

Push notifications should be:

• Timely - It matters right now
• Relevant - Make it personal to your user
• Precise - Specific information that’s good to know or act upon

Good examples of appropriate scenarios for using a push notification is a notification that an upcoming flight is delayed. The push notification should be relevant so it’s important to include information such as the flight number and be precise by including the new departure time.

Sending Push Notifications from your PWAs back-end is not that simple so it’s worth using a Web Push library to accomplish this.

Data properties can be added to the notification options to pass information from the push message to the notificationClick event to for example open a particular URL when the push message is clicked by the user. Furthermore, as the push event is handled by a Service Worker it could also cache the URL a user is likely to access from the push notification before it is delivered.

Using HTTPS ensures:

• Identity - Who you are exchanging information with
• Confidentiality - Who can ready your data
• Integrity - Who can modify your data

If you need further convincing as to the benefits of swapping to HTTPS, consider that many modern browser APIs are only available over HTTPS such as Service Workers, Push Notifications and Geolocation.

The only drawback of switching to HTTPS is performance, as the setup of the secure connection does decrease server response times. But this performance impact of HTTPS can be mitigated by introducing some new technologies:

HTTP Strict Transport Security

This is introduced with a simple header added to the server response:

This says to the browser "only access this website and all its subdomains over HTTPS for the next month". This improves performance by stopping the browser from first requesting a URL over HTTP to then be redirected to HTTPS, essentially removing a round trip from the negotiation.

Further optimisations such as TLS Session Resumption and TLS False Start help to shave off further round trips during the TLS handshake to setup client-server secure connections.

HTTP/2

HTTP/2 unlocks some dramatic performance improvements for HTTPS.

With the introduction of Let’s Encrypt even cost is removed as a factor preventing websites from implementing HTTPS. Other certificate types that are not (yet) available from Let’s Encrypt can be purchased for low cost from providers such as SSLMate.

Google’s Lighthouse tool is a great way to benchmark a PWA, returning scores out of 100 across five key metrics:

• PWA
• Performance
• Accessibility
• Best Practices
• SEO (added January 2018 v2.7)

For humans:

• 0.1s feel instant
• 1s feel natural
• 10s loses the user’s attention

On the mobile web today:

• 19s is the average mobile page load time
• 77% of mobile sites take 10+ seconds to load
• 214 server requests per mobile web page
• 50% of requests are ad related

Accelerated Mobile Pages (AMP) aims to solve this by improving page loading times on mobile devices. AMPs are built with three core components:

• AMP HTML is HTML with some restrictions for reliable performance.
• The AMP JS library ensures the fast rendering of AMP HTML pages.
• The Google AMP Cache can be used to serve cached AMP HTML pages.

Combining AMP with PWAs takes advantage of the benefits of both complementary efforts to improve the Web Platform.

Future Web APIs

The PWA Roadshow has only covered a few of the new and upcoming APIs coming to the Web Platform, there are many more and there just isn’t time to cover them all.  Here are a few of the more notable ones:

Credentials Management API

This is a standards-based browser API that provides a programmatic interface between a website and the browser for a seamless login across devices. It removes friction from user login flows, as users can automatically be signed back in even if their session has expired or if they have saved their credentials on another device. It allows for a one tap sign in that leverages the native account chooser user-interface. The API allows the website or app to store the users credentials and synchronise them across devices, either a username and password combination or even federated account details. The API is supported in Google Chrome and Opera today and Apple has started working on it.

Web VR

Web VR allows developers to create a fully immersive 3D experience in the browser using a VR headset and a VR capable device. Web VR is supported today in Google Chrome, Firefox, Microsoft Edge and Samsung Browser.

Web Assembly (WASM)

Web Assembly provides a new way to run code such as C++ on the web at near native speeds. It provides the speed necessary to deliver demanding applications such as an in browser video editor or running a Unity game at a high frame rate.

After the talks it’s codelab time, where you gets hands-on with some example code to implement some of the ideas and approaches covered in the talks. All of the codelabs are straightforward to follow and produce the the desired results without exception.

Completing the codelabs at my own pace rather than within an allotted time allowed me to really dig into the code and do as much background research and experimentation as I wished. From previous experience, the codelabs on the last PWA training day I attended were often more like cut-and-paste races. Where the winner was the person who could cut-and-paste the code samples from the codelab into their files fastest, which isn’t conducive to actually learning and understanding what the code is doing.

Here are links to the codelabs along with the source code to download:

• Your First Progressive Web App
  Source code: zip, repo
• Debugging Service Workers
  Source code: zip, repo
• Frictionless Payments
  Source code: zip, repo
• Push Notifications
  Source code: zip, repo