Les Progressive Web Apps pour booster l’UX de vos services

À l’origine, le Web était documentaire et organisé en pages. Un très grand nombre de sites obéissent encore à ce paradigme. Depuis le début des années 2000, de nombreux sites se sont enrichis d’interactions via JavaScript pour offrir à leurs visiteurs des usages qui se rapprochent davantage de l’application de bureau que du contenu rédactionnel. Ces applications web (ou Web Apps) souffraient de plusieurs défauts liés aux possibilités offertes par les navigateurs Web jusque-là. L’innovation, le dynamisme des éditeurs de navigateurs et du Web en général ne pouvait laisser cette situation perdurer… ainsi naquirent les Progressive Web Apps.

Le terme Progressive Web App (abrégé PWA) est ainsi un terme apparu récemment à l’échelle du développement Front End, qui définit un ensemble de technologies et de bonnes pratiques qui permettent d’adapter un service web fourni à l’utilisateur pour le rendre accessible au delà des limites traditionnelles du navigateur et, notamment mais pas uniquement, dans des conditions sous-optimales d’accès au réseau (incluant le hors-ligne).

Ces innovations ont le potentiel de changer complètement la manière dont les internautes consomment le Web et les applications sur mobiles.

Quelques exemples de Progressive Web Apps tirés du site https://pwa.rocks/ :

• Wiki Offline (Jake Archibald) : un exemple d’application étendant Wikipédia avec du hors-ligne ;
• The Washington Post PWA : la refonte en PWA du célèbre journal américain, pour davantage de performance au service d’une meilleure expérience de lecture¹ ;
• Devdocs.io : ressources et documentation pour les développeurs, accessible hors-ligne ;
• Pokedex.org : référentiel de 650+ pokémons, accessible hors-ligne.

D’ici peu (nous y reviendrons plus tard), l’utilisateur aura la possibilité d’installer une PWA sur son écran d’accueil, de la même manière qu’une application (avec empaquetage des données, présence dans la liste des applications, informations sur la consommation de mémoire et de batterie…). Ces innovations ont le potentiel de changer complètement la manière dont les internautes consomment le Web et les applications sur mobiles.

Cela vaut la peine qu’on s’y intéresse.

Comment est-ce possible ?

Les PWA reposent sur un ensemble de choses sur lesquelles reposent déjà les Web Apps :

• le Responsive Web Design (RWD), évidemment, pour adapter les interfaces à tous les écrans ;
• des Web Services et Web Sockets exposés par des serveurs et permettant d’accéder à des informations ou de réaliser des actions par le biais d’actions web ;
• certaines API fournies par les navigateurs, qui permettent de tirer pleinement partie du contexte (on aura par exemple accès à des API différentes suivant les capacités du matériel de consultation : audio, vidéo, accélération, géolocalisation, transcription, vibration…).

Elles se distinguent néanmoins par deux composants techniques récents :

• les Service Workers : il s’agit d’une capacité du navigateur à fournir une couche intermédiaire entre la Web App et le réseau, qui tourne en arrière plan (même quand l’application est fermée). Cette couche « réseau » est capable d’écouter et d’émettre des requêtes, des notifications ou de capturer des changements de connectivité ;
• les Web Workers sont également des capacités d’arrière-plan mais plutôt dédiées aux calculs et au développement orienté « Services ».

Progressive Web Apps are experiences that combine the best of the web with the best of apps.
« Your First Progressive Web App », Google Developers Code Labs

Bien réussir ses Progressive Web Apps

Il y a quelques points-clefs à prendre en compte lors du développement d’une application web progressive.

Chargement instantané

L’application doit pouvoir se charger de manière rapide, quel que soit l’état du réseau. La disponibilité du réseau devient alors une amélioration progressive :

• en très haut débit : l’application web affiche une synchronisation totale et instantanée avec le serveur ;
• en navigation bas débit : la mise-à-jour des ressources externes ne doit pas gêner la navigation ;
• en mode hors-ligne : l’application doit être accessible au moins sur la page d’accueil.

Rapidité

L’application doit se comporter de manière extrêmement fluide, dans l’idéal autant qu’une interface d’application de bureau. Pour cela, les développeurs peuvent miser sur l’accélération matérielle en CSS, les requestAnimationFrame en JavaScript, l’optimisation des ressources… et bien sûr le RWD si on souhaite que la PWA s’affiche de manière élégante sur tous les terminaux.

Sécurité

HTTPS est obligatoire dans vos PWA pour sécuriser l’intégralité des échanges entre le navigateur et le serveur, et permettre l’utilisation des Service Workers. Contrairement à une application native dont l’utilisateur n’a aucune idée de la sécurisation, c’est ici le navigateur, composant de confiance, qui affiche un cadenas vert, rassurant pour l’utilisateur.

L’utilisation de Bonnes Pratiques

Les bonnes pratiques sont plus que jamais utiles. Le référentiel OpQuast, non-spécifique aux PWA, est une excellente base de travail. D’autres outils permettront d’auditer spécifiquement le contexte des PWAs, comme Google Lighthouse.

Une mise en garde

Attention au SEO et à l’accessibilité !

Les PWA ne pourront afficher des données récupérées via le navigateur en JavaScript que si celui-ci est disponible. Si cette disponibilité n’est pas assurée, un code isomorphe, c’est-à-dire pensé pour pouvoir s’exécuter sur le serveur, permettra de présenter immédiatement à l’utilisateur une page déjà générée, puis l’améliorera une fois JavaScript disponible. Ceci est rendu possible via différente technologies, la plus populaire dans le cas d’un code isomorphe est l’utilisation de ReactJS².

Identifier les contraintes en amont

En amont, trois contraintes principales doivent être prises en considération avant de démarrer.

Proposer la PWA sur l’écran d’accueil des périphériques mobiles

Faire savoir à l’utilisateur que le site est disponible sous la forme d’une PWA n’est pas chose aisée. Des mécanismes natifs existent comme sur Chrome pour Android, par exemple. Cependant, le navigateur ne va proposer de rajouter la PWA sur la page d’accueil qu’à la seconde visite de l’utilisateur (il faut que cinq minutes se soient écoulés entre les deux sessions). Il faudra donc trouver d’autres méthodes pour prévenir l’utilisateur de cette possibilité et lui donner envie d’y recourir.

Un bon moyen est d’utiliser les notifications push qui sont accessibles au sein du navigateur via une API. Attention à rester fins, car insister auprès de l’utilisateur à coup de notifications et d’emails n’est pas de la fidélisation. Ayez toujours à cœur de valoriser le service apporté par la PWA pour convaincre.

Le support hétérogène suivant les navigateurs

Safari sous iOS ne supporte pas les Services Workers, Apple défendant sa politique de promotion des applications. Cette contrainte, très importante, peut éliminer un certain nombre de cas d’utilisation des PWA. Safari ne proposera pas non plus à l’utilisateur de rajouter la PWA à l’écran d’accueil, mais il est possible de « tricher » en détectant le navigateur côté client et en présentant la procédure d’épinglage à l’écran d’accueil sous iOS. Attention cependant à détecter l’installation de la PWA pour éviter de proposer cette procédure à un utilisateur qui l’aurait déjà suivie !

Les API JavaScript en sont pas supportées de manière équivalente par tous les navigateurs. Par chance, avec la dynamique initiée par le développement de Firefox OS, le navigateur de Mozilla a implémenté énormément d’API et Microsoft Edge essaie de compenser son retard pour rattraper la concurrence. Comme souvent, le site http://caniuse.com/ restera une référence lors du développement, mais on pourra également signaler le bon travail de veille de Jake Archibald sur le sujet.

Support de quelques fonctionnalités en fonction du contexte d’exécution :