26 Aug 2016

Progressive Web App Dev Summit – Feedback

What is it ?

The 20 and 21 of June, I had the chance to attend the Progressive Web App (PWA) Dev Summit in Amsterdam. Formerly known as the Chrome Dev Summit, this event was (very well) organized by Google, but was not a Google products event as all browser vendors were present to give a talk (engineers from Mozilla Firefox, Microsoft Edge, Samsung Internet browser and Opera, the only vendor missing was Apple Safari…).

The event was split in two days :

  • A first day with tech talks by Googlers about different aspects of PWA,

  • And the second day composed by feedback from companies having implemented PWA (Konga, Booking.com), or the vision of major browser vendors.


First Day – PWA Technical Talks


Opening Keynote (Alex Russel @slightlylate – Thao Tran @thaotran)

Alex Russel has retraced the journey of the web on desktop where it has surpassed native applications and predicts the same thing will happen on the mobile platform thanks to PWA.

Then Thao Tran exposes why and how a company should adopt PWA : a step by step transformation driven by business needs and progressive enhancements.


Instant-loading offline-first progressive web apps the next generation part II uncovered (Jake Archibald @jaffathecake)

Jake Archibald, in socks and without a Wiimote, has given a great overview of how to improve UX by providing content instantly to users. Even on Lie-Fi (the lying Wi-Fi). To achieve this, he uses service workers and finely tuned cache strategies.

Results are very impressive and PWA can beat native apps loading time after the first load.

Jake Archibald has also presented the Streaming API which sounds very promising.


Mythbusting Https (Emily Schechter @emschec)

Https is now a prerequisite to benefit all new features for the Web (services workers, push notifications, location, …).In her talk, Emily Schechter removes the barriers three companies imposed to themselves about implementing https :

My site is not important enough

Https not only guarantees the security of the users, it also guarantee their UX : many public Wifi networks tamper the http stream by adding their data, for example ads. The results is a defaced original content with a degraded experience.

The impact on performances

Https has a real impact on the number of round trips :

  • Http redirect

  • Certificate handshake

  • Request

There are tips to reduce these impacts :

  • The Http Strict transport Security tells the client that a site is only accessible through https,

  • The duration Http handshake can be reduced by using the TLS False Start to send the http request in the middle of the TLS handshake,

  • Time can also been saved by reusing the session,

  • Http/2!

The cost

There are now cheap (sslmate.com) and even free (letsencrypt.org) certificates authority. To reduce the search engines confusion during migration (same page exists with http and https URLs), apply best practices like the use of canonical links and the search engines redirection.

The dependencies with third parties companies don’t manage

Have third parties (ads, referrers, mixed content) to implement https too ?

  • Many ads provider already use https, for example Adsense,

  • The removal of referrer when using https (for privacy reasons) can be compensated by the use of the Referrer-Policy header.

  • The mixed http/https contents causes the removal of the Green Lock in Chrome This can be mitigated by the use of a Content-Security header which will specify the type of resources that are allowed to be loaded on http. This rules are testable using the report-only mode in which reports are sent to identify (but not block) resources loaded over http. Chrome DevTools security panel can also help the developer to achieve this.


Https used to be seen as complex, expensive and slow but now it is easer, faster and cheaper… and a requirement for PWA !


Instant Loading with HTTP/2 (Surma @DasSurma)

Service workers are a great help for instant loading, but what to do before the service worker has data locally available ?

Deliver assets fast

Enable compression (one line of code in the server configuration) allows a 80% performance gain.

Round trip time

The round trip time is the time needed by the signal to travel from the client to the server and to come back. It is :

  • 50 ms on WiFi,

  • 500 ms on 3G,
  • 2500 ms on 2G.

A site needs , on average, 100 requests on 6 available connections…

Reduce impact of JS and CSS loading

To reduce the impact of RTT, use non blocking techniques to load assets, for example

  • The defer and async attributes of the script tag (use both),

  • The loadCss tool from filementgroup to load CSS asynchronously,

  • Inline critical CSS,

  • Defer the loading of iFrames with JS.

Cache data

Implement a fined tuned cache strategy with cache validation headers :

  • Etag as a strong cache validator,

  • Last-modified header as a weak cache validator,

  • Cache-control to define the cache strategy

  • Expires to define the validity duration of assets


Http/2 allows uses only 1 connection (contrary to http 1.1 which uses 6 connections) but allows to multiplex http request and response on this single connection. It is also able to compress and not resend headers.

Http/2 also offers Server Push which allows the server to include in the response asset that were not asked by the request. This feature is used by the PRPL pattern promoted by Polymer (Push, Render, Pre cache, Lazy load).


Deep Engagement with Push Notifications (Owen Campbell-Moore @owencm)

Push notifications allows a user engagement level similar to native apps. This feature is very powerful and must be used with parsimony : is the information important enough to warrant an interruption ?

Questions to ask yourself when designing a push notification :

  • When : is it timely ?

  • What : is it precise ?

  • What and who : is it relevant ?

… and when to offer the user the ability to activate them for a site (for example, WeatherChannel proposes push notification on its configuration page).

There are two types of notifications :

  • Tickel (without payload),

  • With payload.

Payload encryption is mandatory, use web-push-libs on server side to achieve proper push notifications. On client side, service workers with an event listener allow to deal with push notification from the server. It is also possible to improve the UX on notification by using action buttons directly on the notification.


UI Elements at 60fps (Paul Lewis @aerotwist)

Paul Lewis introduces its talk with the RAIL performance model (Response < 100ms, Animation every 16ms, Idle < 50ms, Load < 1000ms). He then gives techniques to improve the fluidity perceived by the user :

  • The navigation drawer is animated with transform and opacity CSS properties instead of manipulating position (top, right, bottom, left) and the position (absolute) of an element. Also use the CSS property will-change:transform to promote the element and inform the browser that the element is eligible for animation.

  • Swipeable cards also use element promotion when the card is touched,

  • Expandable and collapsible cards are implemented using the FLIP pattern (First, Last, Invert, Play), which aim is to calculate the reverse animation of what should happen, and then rewind it to get the expected behavior. All that process has to be short enough to fit in 100ms (the delay between the user action and the first render).


Progressive Web Apps in Any Context (Rob Dodson @rob_dodson)

This talk was about UX and accessibility (a11y). Rob Dodson begins with a presentation of the diversity of users: 15% of users have one form of disability (visual, motor, auditory, cognitive). To provide a proper experience to all users, guidelines are provided for a11y by W3C with Web Content Accessibility Guidelines. Here are a few best practices :

  • Use HTML focusable elements to interact : button, radio, select, … instead of div,

  • Add tabindex on non focusable elements to make them focusable,

  • Using the roving tabindex allows to modify the tab index on the fly according to elements displayed or hidden (prevent tab index to access element out of the screen, for example an hidden navigation drawer),

  • Add visibility:hidden to element after hiding animation finishes,

  • Use implicit element semantics to create an accessibility tree and simplify the screen reader tasks.

Some tools ease the development of ARIA (Accessible Rich Internet Applications) like the accessibility panel in the Chrome DevTools.


Progressively Enhanced Markup: Using Web Components to Build PWAs (Eric Bidelman @ebidel)

This talk is a reminder of what the Web Components are : a set of emerging standards. Eric Bidelman then focuses on a few key points of Web Components :

  • Custom elements : allows to create your own markup element, they can inherit from existing HTML elements,

  • Shadow DOM : allows to isolate the component style and markup from the rest of the DOM,

  • CSS Custom Properties : allows to define custom CSS properties for your element, for example the –my-custom-color which should be the element dominant color used for texts, borders, shadows, etc…


Putting the Progressive in Progressive Web Apps (Paul Kinlan @Paul_Kinlan)

Paul Kinlan starts his talk with a reminder of what is progressive enhancement : use ASAP new browser API to provide a better user experience while ensuring fallback for old browsers. Then he describes the four key points of a progressive web app :

The appshell

In many web applications, there is a lot of wasted time in downloading and parsing all resources before displaying anything. The goal of the appshell is to minimize and cache the required resources for the first display to show minimal content ASAP and then load other resources to display fresh data for example. This is progressive render + bootstrap.

Push notifications to re-engage users

Push notifications are a great way to re-engage your users. But to be used, they have to be supported by your OS/browser (iOS does not support them for now). So check their support and eventually provide an alternate notification mechanism by using email, SMS or social networks.

To be effective, Push notifications must be timely and relevant, so think about your use case.


Installation features provides native like experience to start interacting with an application.

There were initiatives to allow this experience on iOS with a “Add to homescreen” feature and the Android “Add widget” feature, but those were not standardized and provided a suboptimal user experience.

manifest.json is now the standardized way to allow a web application to be available from the user homescreen.

A consequence of the installation of web applications is that a poor offline experience is no more accepted by users.


Technical solutions to provide offline experience existed for years but were not satisfying (do not use appcache!). To achieve a good offline experience, begin with building resilience on the client side first and then enhance with service workers… and be pragmatic !


Tools for Success (Mat Scales @wibblymat)

Mat Scales begins his talk by presenting the evolution of the Web from pages using directly the web platform API to apps using libraries masking low level API complexity. This new paradigm makes new tool emerge.

Service workers libraries

Service worker API is complex. Google provides two libraries to mask SW API complexity :

  • sw-toolbox provides helpers to create and manage service workers and their caching strategies,

  • sw-helpers is a collection of libraries providing commonly-needed functionality :

    • sw-appcache-behaviour allows to use appcache when service workers are not implemented in the browser,

    • sw-offline-google-analytics allows to track application usage offline, analytics data are sent when a connection is available.

Chrome Devtools

The Chrome Devtools “Resources panel” has become the “Application panel” and now provides functionalities for PWA :

  • A manifest viewer,

  • A revamped service workers UI,

  • Clear storage shortcuts,

  • A cache storage viewer.


Lighthouse is a tool checking that all PWA concepts are implemented in your application (the PWA Acid test). It scores your page and gives hints to improve your application.

A Chrome extension exists to ease Lighthouse use.


To the Lighthouse (Jeffrey Posnick @jeffposnick)

Jeffrey Posnik explains in his talk how to migrate an existing application to PWA by using the Lighthouse tool, a tool checking that all PWA concepts are implemented in your application :

  1. Use lighthouse on your existing application to establish a baseline,

  2. Add server side rendering, then check improvement with Lighthouse,

  3. Add service workers (appshell and dynamic content model),then check improvement with Lighthouse,

  4. Add a manifest, then check improvement with Lighthouse.


Building for Billions (Tal Oppenheimer @taloppenheimer)

This talks explains how to build an application for the largest range of users. To do that, the first thing to do is to understand them, their needs and their constraints :

  • There are users that will only access your application through mobile device, so design mobile first,

  • Their type of device : from the most to the less powerful (Nexus 6P : 3GB RAM/32GB storage VS Samsung J1 : 1GB RAM / 8GB storage)

  • Their quality and type of connectivity :

    • 20% of US households rely only on cellular data, 60% of mobile connections are 2G,

    • 1 second delay in pages times leads to 11% fewer page views and 16% decrease in customer satisfaction,

  • Connectivity cost : in India, it costs 1hr of minimum wage work to load allows to load about 15 web pages

Depending of all those constraints, application install can be expensive (APK sizes and updates). PWA addresses most of the previous constraints and allows to improve your users experience :

  • Cost :

  • Connectivity :

    • Use the NetworkInformation.downlinkMax property to identify the network capacity and adapt your service workers activity,

    • Provide offline features, for example an offline checkout process finishing with a phone call to complete the order,

  • Complexity :

    • Every step in your application process is time and money, try to reduce those steps,

    • Especially by using :

      • the add to home screen feature which allows to reduce extra navigation to access your site,

      • The push notification to create deep link to key parts of your user experience.

It is possible to test those improvements on different device types thanks to the Mini Mobile Device Lab. Understand the cost of your application by identifying the payload transferred and the finish time thanks to Chrome Devtools.


Closing Keynote – The Future of Progressive Web Apps (Chris Wilson @cwilso)

Chris Wilson exposes the next challenges for PWA.

Know who the user is

Today, the login experience is improved with autocomplete and social login, but it may still be painful on mobile (typos in mail, difficult access to special characters). The login experience could be enhanced by avoiding the user to fill a form with, for example, a transparent login, to achieve this, the credential management API is needed (https://developer.mozilla.org/en-US/docs/Web/API/Navigator/credentials).

Enable payments

Today, there is 66% fewer conversion on mobile website than on desktop website. This is due to the checkout forms complexity : checkout forms are manual, tedious slow and needs N-taps.

To mitigate this, it is possible to use Chrome autofill feature.

The next step should be to completely remove the payment form from the checkout process thanks to the (not ready yet) Payment Request API.

Connect to hardware

The improvement of Bluetooth Low Energy (BLE) and the introduction of the Web Bluetooth API now allows interactions between a web application and hardware. This is made thanks to Generic Attribute Profile (GATT) which defines a communication protocole to exchange informations between nearby bluetooth devices and the browser.

The typical architecture to achieve this communication is a central device (the phone or computer), a peripheral device (the bluetooth device) and a GATT server. The GATT server accesses the peripheral device information and exposes them in a standardized way to the central device.


Second Day – PWA feedbacks


Konga: Learnings from Building a Progressive Web App with Polymer (Andrew Mori @mulleta)

Konga is an ecommerce company in Africa and especially in Nigeria. 57% of its customer are on mobile devices with 2G. They choosed PWA because of native applications cost for install and upgrade, the degradation of UX on poor networks and to be able to adapt to fast paced business changes.

Konga implemented PWA incrementally :

  1. Mobile web redesign

  2. Offline first

  3. Application manifest

  4. Service workers

And then migrate to PWA :

  • App shell implementation :

    • Load static content,

    • Cache HTML/CSS/JS,

    • Splash screen display,

    • Vulcanize to optimize assets,

  • Background synchronisation :

    • Analytics, tracking offline events,

    • Offline checkout with phone call to complete orders,

  • Polymer integration without third party libraries (Plain JS only, no JQuery, Angular),

  • NPM + Bower.

They also carefully define each web component they develop to ease their reuse thanks to a custom component’s repository.

The encountered difficulties were :

  • The Safari support,

  • The learning curve (especially for developers coming from native apps development),

  • The modularity of web components and its consequences on styling,

  • CORS.

Konga did a beta launch of its PWA focusing on offline features :

  • Offline catalog,

  • Offline wishlist,

  • Phone call to complete orders.

In forthcoming released, they plan to :

  • Measure and track events offline,

  • Improve offline experience,

  • Add native push notifications,

  • Improve cross browser support.


Samsung Internet’s Progressive Web App Commitment (Daniel Appelquist @torgo & Jungkee Song @jungkees)

Samsung Internet is the default browser on Samsung mobile devices and Gear VR. Samsung contributes to Chromium and uses it as a basis for its browser, “A commitment to web standards”.

It only supports Samsung devices but benefits from auto-updates from the Play Store.

Samsung participated to the service workers implementation since 2 years thanks to its Chromium contributions.

Samsung Internet wants to provide a “thematic consistency” by offering a coherent experience across different devices.


PWA in Small Steps – How do Booking.com improve mobile web experience with service workers progressively? (Jesse Yang)

Before implementing PWA concepts, Booking.com :

  • Already had an optimized web site,

  • Had a large code base,

  • Was concerned by developers perturbation,

  • Tests every changes.

Booking.com chooses “the smallest viable steps” approach :

1- Make the confirmation page accessible offline allowed to :

=> Understand traffic sizes,

=> Clear potential roadblocks,

=> Observe side effects :

  • More page views because confirmation page is now available from cache,
  • An increase in page load time (no cache optimisation so no caching impact, but service workers are suspected to consume more CPU),
  • No impact on conversion,

2- Implement the add to home screen to allow access to the last cached confirmation page,

=> most users ignore the banner

3- Modify the “Add to homescreen” invitation to make it contextual.


Jesse Yang conclusion is that you need to “find an approach that fits your business” to implement PWA.


Progressive Web Apps in Firefox (Ben Kelly @wanderview)

Service worker

Firefox began its PWA journey in April 2014 by implementing the service worker API and shipped it in Firefox 44 in January 2016. This delay is because Firefox team was waiting for :

Push notification

Push notifications are, for now, only implemented on desktop (shipped in Firefox 44), planned for Firefox for Android 48. Firefox has :


Service worker console is available at about:serviceworkers. It allows to:

  • Debug service workers (fetch & push),

  • See network queries in the network panel,

  • Inspect cache storage.

Application manifest

Manifest is supported except for the Add to home screen. An experiment exists for this feature but it does not use the manifest.

Background sync

Background sync is a work in progress.


Mozilla cares about the Web, it wants to success on mobile and continue in investing in Web API.


Microsoft: Keeping the Progressive in Progressive Web Apps (Patrick Kettner @patrickkettner)

Microsoft wants the users to “use the latest web technologies”.

Application manifest

Microsoft provides a tool to automatically create application manifest for existing applications.

Service workers

Service workers are a great part of PWA but they suffer from their lack of support (75% of audience supports SW). It is possible to use older APIs to do the service workers job : appcache.

Web workers

There are not a part of PWA but allows application to be fast. This old API solves the main Web problem : it is single threaded. Web workers allows to offload tasks to a background thread.


This old API use was not really spread because of its complexity. But there are wrapper to hide its complexity like Dexie.


Use the new shiny, do feature detection, use fallbacks.


Progressive Web Apps: Opera’s Perspective (Andreas Bovens @andreasbovens)

Andreas Bovens first listed what Opera has added support for :

  • Add to home screen,

  • Service workers / offline,

  • Push notifications,

  • Background sync will be soon available.

Then, he presented some UX patterns related to PWA.

UX patterns : Channel the users to install banners

How to channel the user to install banners :

  • Use the mechanism provided by the browser : the install banner is displayed when a user frequently uses your application,

  • Mute the default behaviour and provide :

UX patterns : Use display mode other than standalone

The display:browser allows to always display the browser controls and access to URL and navigation controls, implemented on https://www.theguardian.com.

The display:fullscreen and orientation:portrait can be used in games for an optimal immersion.

UX patterns : Saving specific contents units or (almost) all site

Save offline specific content like https://www.soundslice.com/ which allows to save sheet music offline.

It is also possible to save almost the entire site like does the https://www.washingtonpost.com/. It is possible to browse news and read article offline, but only text is saved. Images are, in this context, not displayed and need a connection to be (lazy-)loaded.

UX patterns : Indicating that the user is offline

It is possible to inform the user he is offline through different ways :

UX patterns : Using notifications for re-engagement and contextualizing why you need permissions to send notifications

Push notifications allows re-engagement without signing or downloading an update. The permissions to send push notifications must be asked at the right moments :

  • In settings,

  • After login,

  • On checkout, …

  • But not on first load of the application !

Issues and ideas

Andreas Bovens finished his talk with some issues and ideas :

  • “You’re offline” is outdated, replace-it with “The site does not work offline” : do not blame the user anymore for being offline, blame the application for not working offline !

  • A “Add to homescreen” button in browser controls bar,

  • Add a special gesture to open fullscreen PWA in the browser to access browser controls bar and be able to manipulate URLs.


The summit ended with a session of questions and answers between the audience and the speakers :


Concerning PWA

PWA are really a breakthrough in web technologies by providing a bunch of great features to tease native applications :

  • Service workers and offline,

  • Add to homescreen,

  • Push notifications,

  • Background sync.

It is possible to implement those concepts step by step to progressively migrate your application to PWA. Do not wait for all browsers to support those new standards, implement them right now and provide fallback.

Concerning the event

The PWA Dev Summit was really a great event :

  • The tech talks by Googlers were amazing,

  • The feedbacks and other vendors point of view were a real proof of openness of this event,

  • It was a great opportunity to chat with engineers from Google and from major browser vendor, and to other developers,

  • The organisation was perfect : great venue, great food and great party !