Cela fait quelques années que les PWA agitent le petit milieu du développement web. Présentées comme une solution à mi-chemin entre les applications natives et les sites classiques, installables d'un clic, elles paraissent encore nébuleuses pour beaucoup. Voici nos explications, par l'exemple.

Que de chemin parcouru par le Web. Né à la fin des années 80, il a été pensé pour transmettre le savoir à travers Internet et les hyperliens. Popularisé dès les années 90, il est désormais partout. Jusque dans vos TV connectées et peut être même votre prochain frigo (ou pas). Ce qui ne l'empêche pas de continuer à faire face à quelques défis.

Une continuité dans l'évolution du web

Ces dernières années, il a profondément évolué. L'émergence des usages mobiles a notamment changé la donne. Les sites web ont dû apprendre à s'adapter à différents écrans et des connexions parfois aléatoires. Mais aussi à être de plus en plus considérés comme des applications à part entière, le fameux SaaS (Software-as-a-Service).

Les standards que sont JavaScript et HTML (entre autres) se sont eux aussi transformés, devenant de plus en plus asynchrones, réactifs, s'accompagnant d'API toujours plus complètes pour tirer parti des capacités des appareils. Avec Node, JavaScript est même devenu un langage exploitable côté serveur, modulaire grâce à npm. 

De quoi constituer une alternative ouverte et globale face aux écosystèmes logiciels spécifiques à chaque plateforme, renforcés par les boutiques applicatives qui enferment tant les utilisateurs et les développeurs. Un long chemin, nous menant peu à peu aux Progressive Web Apps, un concept né en 2015.

Désormais gérées par tous les grands navigateurs, que sont-elles réellement ? Leurs promesses sont-elles tenues ? Plutôt que de simplement multiplier les explications théoriques, nous allons vous expliquer comment héberger (gratuitement) un petit site en ligne avant d'en faire une PWA. Et c'est bien plus simple que vous le pensez.

• La révolution des applications web progressives (PWA)
• Hébergeons un site statique avec accès sécurisé (à venir)
• Créez votre première PWA (à venir)

Du Web 2.0 aux Progressive Web Apps

L'idée d'un web « applicatif » n'est pas née il y a cinq ans. D'une certaine manière, c'était le sens de l'histoire, avec l'émergence de sites qui n'étaient plus tant des moyens de diffuser de l'information, mais des outils.

Ainsi, les clients emails en ligne étaient parmi les premières applications accessibles par internet. Mais à l'époque de Caramail, on ne parlait pas encore de SaaS. On l'oublie souvent, mais aux débuts de l'iPhone Steve Jobs lui-même vantait une approche similaire, avec des applications profitant des standards, accessibles depuis Safari.

On était en 2007, en pleine révolution du « Web 2.0 » et de l'AJAX (Asynchronous JAvascript and Xml). Apple vantait les applications web pouvant interagir avec les services natifs d'iOS (appels, emails, géolocalisation), sans problème de distribution ou de contrainte de mise à jour. Une solution sécurisée, isolée du reste du système (via un bac à sable, ou sandbox) pour limiter les failles. Les SDK présentés comme l'approche à éviter :

Mais le grand bouleversement qu'allait être HTML5 n'en était même pas à ses prémices. Le web n'était pas encore prêt à devenir une plateforme pour les applications du quotidien. Cette stratégie, qui avec le recul peut être perçue comme l'un des premiers plaidoyers en faveur des Progressive Web Apps, est vite abandonnée au profit des applications natives et de l'App Store (dès 2008), avec le succès et les contraintes que l'on connait.

Safari n'est alors plus vu comme un moyen de conquête. Sa version Windows sera abandonnée en 2012. Désormais, Apple a plutôt tendance à freiner sur le support des PWA dans Safari, perçues comme une menace pour sa stratégie d'écosystème logiciel centralisé où il fait office de péage, surtout pour tout ce qui touche au paiement.

Mais le reste du marché a sauté le pas, comme nous l'avions évoqué l'année dernière. Notamment Google qui y voit un intérêt pour le développement de ses Chromebooks. Les navigateurs ont terminé de digérer l'arrivée de HTML5 (finalisé en 2014) puis ECMAScript 2015, servant de base au JavaScript moderne (qui a encore évolué depuis).

Il était donc tout naturel que de nouvelles évolutions prennent le relais. C'est le rôle des Progressive Web Apps qui ne sont pas un nouveau standard, mais bien un concept général reposant sur des briques existantes.

Les PWA, un concept plus qu'un nouveau standard

Il faudra donc attendre près de 10 ans après la vision de Steve Jobs pour le premier iPhone avant que cette dénomination ne soit trouvée. C'est le 15 juin 2015 qu'Alex Russell, ingénieur chez Google depuis 2008, publie le billet de blog fondateur des PWA, sobrement intitulé S'échapper des onglets sans perdre notre âme.

Il y évoque différentes tentatives précédentes visant à utiliser les standards du web pour concevoir des applications, leurs ratés et leurs limites. D'Adobe Air à Electron en passant par Firefox OS ou WebOS. Pour lui, l'un des problèmes communs est de ne pas avoir répondu aux questions de découverte/distribution, ou de l'avoir fait à travers des solutions centralisées. En plus d'avoir mis de côté certains problèmes vitaux à résoudre.

C'est pour cela qu'il a travaillé avec Frances Berriman sur une liste de critères correspondant à ce que devrait être une application moderne basée sur les standards du web, dite progressive. Il faut ainsi comprendre que la notion de PWA n'est rien de plus. Elles ne sont pas formalisées à travers un document technique du W3C ou de l'IETF.

Selon ces critères elles doivent disposer d'un design responsive, s'adaptant à tous les écrans. Se charger uniquement depuis une connexion sécurisée (via TLS). Fonctionner même lorsque le débit est réduit ou que le réseau est hors de portée, via des mécaniques de cache. Mais en étant constamment à jour.

Elles doivent également être utilisables comme une application native au sein du système, découvrable comme telle, installable, tout en restant accessible d'un simple lien : « le pouvoir social des URLs compte » précise Russell. Les API du système doivent lui être accessibles, notamment pour le réengagement, comme les notifications.

Google a depuis publié sur son site consacré aux développeurs sa propre liste de ce qui est reconnu dans son écosystème comme une PWA. Elle prend forme au sein de son test de performances/conformité Lighthouse (voir ci-dessous). On y trouve des notions complémentaires concernant les performances et l'accessibilité :

Le résultat Lighthouse du projet que nous développerons dans la suite de ce dossier

Cette absence de définition figée dans le marbre est sans doute ce qui rend la notion de PWA difficile à appréhender. Mais aussi ce qui a le plus contribué à son succès. Car elle ne se substitue pas à des éléments déjà en place. Elle propose de les faire travailler ensemble avec une liste d'objectifs définis, de cases à cocher.

Une histoire de manifeste

N'importe quel site est donc une application web progressive en puissance. Chacun est libre d'en construire avec les technologies qu'il souhaite. Il y a néanmoins deux éléments incontournables pour les développeurs, afin d'atteindre le résultat désiré : les Web App Manifest et Service Workers. Ce sont eux qui sont standardisés et doivent être gérés par les navigateurs pour qu'ils soient considérés comme « PWA ready ».

Le premier est un fichier texte au format JSON. Il permet au navigateur, mais aussi aux moteurs de recherche et autres outils de distribution, de découvrir l'application et de récupérer ses informations de base servant à l'installation. Une phase qui consiste simplement à créer un raccourci via l'écran d'accueil sur mobile ou le menu démarrer sur Windows 10. Microsoft devrait aussi l'exploiter via winget lorsqu'il permettra l'installation des PWA.

Le manifeste contient donc le nom de l'application, ses codes couleurs, la manière dont elle doit s'afficher (en plein écran, avec plus ou moins d'éléments d'interface), quelques références techniques ou encore son logo :

Le manifeste de l'interface web de Twitter, qui est une PWA : vu par Firefox (à gauche), brut (à droite)

Pour ce dernier, Google incite à passer aux maskable icons du standard, renvoyant vers une application de création. Elles se distinguent par une safe zone pour s'adapter à n'importe quelle forme de découpage (rond, carré, à bords arrondis, etc.) et un fond de couleur présent dès l'origine. Elles sont utilisées en priorité.

De son côté, Apple continue de se baser sur les META spécifiques à iOS, notamment pour cette icône. Espérons que l'éditeur finira par suivre le standard dans de prochaines versions de Safari pour limiter les déconvenues.

Les Service Workers, la vraie spécificité des PWA

Le second élément spécifique aux PWA sont les Service Workers. Il s'agit d'un type particulier de Web Workers, des JavaScript qui s'exécutent en tâche de fond au sein du navigateur, dans un thread séparé de celui du site. Ils communiquent avec ce dernier via une mécanique d'envoi/réception de messages.

Ils ont un cycle de vie particulier. Une fois « installés » puis activés, ils sont capables de se mettre en veille, de s'éteindre indépendamment du fait que le site soit ouvert. Parfait pour gérer des notifications par exemple. Un seul Service Worker est actif par site, chaque onglet agissant comme un « client » qui communique avec lui.

Lorsque l'utilisateur navigue sur le site, le Service Worker local est régulièrement comparé avec celui présent sur le serveur. Si le moindre octet a été modifié, la PWA en est alertée. Démarre alors un cycle de renouvellement, pensé pour éviter les conflits dans le comportement du site. Cela peut se faire de manière transparente, ou à travers une alerte envoyée dans l'interface. Mais la mise à jour d'une PWA passe en général par celle de son cache local.

Une question de cache et de mise à jour

Car la particularité principale des Service Workers est qu'ils agissent comme une sorte de proxy entre le site et la connexion internet. Ainsi, ils peuvent intercepter toute requête effectuée, dans la limite de leur scope (désignant un répertoire du domaine, ou sa racine) ou vers des sites tiers (s'ils acceptent les requêtes cross-origin via CORS).

L'intérêt principal de cette capacité est qu'ils peuvent être utilisés pour mettre en place une stratégie de cache. Ils sont ainsi les dignes héritiers d'AppCache, introduit avec HTML mais qui était trop limité. Pour le développeur, une fois tout défini, c'est presque transparent, des outils comme Workbox se proposant de lui simplifier la vie. 

On peut ainsi imaginer une architecture de base des pages devant être mise en cache, remplie ensuite côté client au fil de la navigation. Mais cela ne convient pas à tous les cas, notamment parce que cela empêche la navigation lorsque JavaScript n'est pas actif. Il est donc possible d'effectuer un rendu côté serveur, puis de gérer certains éléments.

Ou d'opter pour une approche hybride, mêlant premier rendu côté serveur et mise à jour côté client. C'est notamment ce que nous faisons sur Next INpact v7. Tout est techniquement possible, avec plus ou moins de difficulté, allant jusqu'à la création d'un site complet accessible hors-ligne.

Les ressources à mettre en cache sont au choix du développeur, qui peut se limiter aux images ou intégrer également les pages, leurs scripts et feuilles de style, le contenu, etc. Tout dépend du besoin. Les frameworks proposent en général de gérer finement la mise à jour, par exemple avec une table d'empreintes. Lorsque des éléments sont modifiés, ils sont renouvelés en tâche de fond. L'utilisateur doit rafraîchir la page pour en profiter.

Des mécaniques plus complexes, basées sur une synchronisation périodique font leur début, nécessitant des permissions spécifiques de la part de l'utilisateur. Mais Google est pour le moment le seul à travailler sur le sujet, l'implémentation n'étant effective qu'à partir de Chrome 80.

C'est ce cache qui permet aux PWA de répondre même lorsque le réseau est absent. Il passe par un stockage propre à chaque application, indépendant de celui du navigateur. Mais d'autres outils sont à la disposition des développeurs, comme les bases de données locales IndexedDB par exemple.

Au final, l'utilisateur est gagnant puisqu'il dispose d'une application qui est presque toujours à jour, ne nécessitant pas de passer par une boutique applicative, limitant ses besoins en données avec un cache programmable de manière assez fine. Le tout avec l'accès à de très nombreuses API, des connexions sécurisées via WebAuthn/FIDO2, et sans doute bientôt des performances encore améliorées avec la généralisation de Web Assembly.

De nombreux sites étant déjà des PWA, vous pouvez voir leur manifeste, leur Service Worker ou le contenu de leur stockage au sein des outils développeurs de votre navigateur. Dans la suite de ce dossier, nous vous apprendrons à développer un site accessible de manière sécurisée, récupérant et traitant le contenu d'un fichier JSON. Avec une méthode classique puis en le transformant en PWA avec mise en cache. Installable sur n'importe quel appareil.