Les progressive web apps ont fait l'objet de nombreuses discussions ces derniers temps. Il s'agit d'un modèle relativement nouveau, mais ses principes peuvent également améliorer les applications créées avec Vanilla JS, React, Polymer, Angular ou tout autre framework. Dans cet article, je vais résumer quelques options et applications de référence pour vous aider à créer votre propre progressive web app dès aujourd'hui.
Qu'est-ce qu'une progressive web app ?
Il est important de se rappeler que les progressive web apps fonctionnent partout, mais qu'elles sont optimisées dans les navigateurs récents. L'amélioration progressive est un pilier du modèle.
Aaron Gustafson a comparé l'amélioration progressive à un M&M's à la cacahuète. La cacahuète est votre contenu, l'enrobage en chocolat est votre couche de présentation et le JavaScript est la coque en sucre. La couleur de cette couche peut varier, et l'expérience peut être différente selon les fonctionnalités du navigateur utilisé.
Imaginez que la coque en sucre est l'endroit où de nombreuses fonctionnalités de progressive web app peuvent résider. Elles combinent le meilleur du Web et des applications. Elles sont utiles aux utilisateurs dès leur première visite dans un onglet de navigateur, sans qu'aucune installation ne soit requise.
À mesure que l'utilisateur se familiarise avec ces applications en les utilisant de manière répétée, elles deviennent encore plus attrayantes : elles se chargent très rapidement sur les connexions réseau lentes (grâce au service worker), envoient des notifications push pertinentes et disposent d'une icône de premier plan sur l'écran d'accueil de l'utilisateur, qui peut les charger en tant qu'expériences dans l'application plein écran. Ils peuvent également profiter des bannières intelligentes d'installation d'applications Web.
Les progressive web apps sont
- Progressives : elles fonctionnent pour tous les utilisateurs, quel que soit le navigateur choisi, car elles sont conçues avec l'amélioration progressive comme principe de base.
- Responsive : s'adapte à tous les facteurs de forme, ordinateurs, mobiles, tablettes ou autres.
- Indépendance de la connectivité : les service workers permettent de travailler hors connexion ou sur des réseaux de mauvaise qualité.
- Comme une application : utilisez le modèle de shell d'application pour proposer une navigation et des interactions de type application.
- Actualité : toujours à jour grâce au processus de mise à jour du service worker.
- Sécurisé : diffusé via TLS pour empêcher l'espionnage et garantir que le contenu n'a pas été altéré.
- Découvrables : elles sont identifiables en tant qu'applications grâce aux fichiers manifestes du W3C et au champ d'application de l'enregistrement du service worker, ce qui permet aux moteurs de recherche de les trouver.
- Réengageable : facilitez le réengagement grâce à des fonctionnalités telles que les notifications push.
- Installable : permet aux utilisateurs de "conserver" les applications qu'ils trouvent les plus utiles sur leur écran d'accueil, sans avoir à passer par un magasin d'applications.
- Lien : partagez facilement via une URL sans installation complexe.
Les progressive web apps ne sont pas non plus réservées à Chrome pour Android. Ci-dessous, nous pouvons voir la progressive web app Pokedex fonctionner dans Firefox pour Android (bêta) avec les fonctionnalités d'ajout à l'écran d'accueil et de mise en cache du service worker qui fonctionnent parfaitement.
L'un des aspects intéressants de la nature "progressive" de ce modèle est que les fonctionnalités peuvent être débloquées progressivement à mesure que les fournisseurs de navigateurs améliorent leur compatibilité. Les progressive web apps telles que Pokedex fonctionnent également très bien dans Opera sur Android, avec quelques différences notables dans l'implémentation :
Pour en savoir plus sur les progressive web apps, lisez l'article de blog d'Alex Russell qui les présente. Paul Kinlan a également créé un tag Stack Overflow très utile pour les progressive web apps.
Principes
Fichier manifeste d'application Web
Le fichier manifeste permet à votre application Web d'avoir une présence plus native sur l'écran d'accueil de l'utilisateur. Il permet de lancer l'application en mode plein écran (sans barre d'URL), de contrôler l'orientation de l'écran et, dans les versions récentes de Chrome sur Android, de définir un écran de démarrage et une couleur de thème pour la barre d'adresse. Il permet également de définir un ensemble d'icônes par taille et densité utilisées pour l'écran de démarrage et l'icône de l'écran d'accueil mentionnés ci-dessus.
Vous trouverez un exemple de fichier manifeste dans Web Starter Kit et dans les exemples Google Chrome. Bruce Lawson a écrit un générateur de fichiers manifestes, et Mounir Lamouri a également écrit un outil de validation de fichiers manifestes Web très pratique qui mérite d'être consulté.
Dans mes projets personnels, j'utilise realfavicongenerator pour générer des icônes de la bonne taille pour le fichier manifeste de l'application Web et pour une utilisation sur iOS, sur ordinateur, etc. Le module Node favicons peut également obtenir un résultat similaire dans le cadre de votre processus de compilation.
Les navigateurs basés sur Chromium (Chrome, Opera, etc.) prennent en charge les fichiers manifestes d'application Web. Firefox développe activement la prise en charge et Edge les liste comme étant en cours d'examen. WebKit/Safari n'ont pas encore publié de signaux publics concernant leur intention d'implémenter la fonctionnalité.
Pour en savoir plus, consultez Installable Web Apps with the Web App Manifest in Chrome for Android (Applications Web installables avec le fichier manifeste d'application Web dans Chrome pour Android) sur Web Fundamentals.
Bannière "Ajouter à l'écran d'accueil"
Chrome sur Android permet d'ajouter votre site à l'écran d'accueil depuis un certain temps, mais les versions récentes permettent également de suggérer de manière proactive l'ajout de sites à l'aide de bannières d'installation d'applications Web natives.
Pour que les invites d'installation de l'application s'affichent, votre application doit :
- Disposer d'un fichier manifeste d'application Web valide
- Être diffusé via HTTPS (consultez letsencrypt pour obtenir un certificat sans frais)
- Disposer d'un service worker valide enregistré
- être visité deux fois, avec au moins cinq minutes d'intervalle entre les visites.
Plusieurs exemples de bannières d'installation d'application sont disponibles, allant des bannières de base à des cas d'utilisation plus complexes, comme l'affichage d'applications associées.
Service worker pour la mise en cache hors connexion
Un service worker est un script qui s'exécute en arrière-plan, indépendamment de votre page Web. Il répond aux événements, y compris aux requêtes réseau effectuées à partir des pages qu'il diffuse. Un service worker a une durée de vie intentionnellement courte.
Elle se réveille lorsqu'elle reçoit un événement et ne s'exécute que le temps nécessaire pour le traiter. Le service worker vous permet d'utiliser l'API Cache pour mettre en cache des ressources et peut être utilisé pour offrir aux utilisateurs une expérience hors connexion.
Les service workers sont très utiles pour la mise en cache hors connexion, mais ils offrent également des gains de performances significatifs sous la forme d'un chargement instantané pour les visites répétées sur votre site ou votre application Web. Vous pouvez mettre en cache votre shell d'application pour qu'il fonctionne hors connexion et remplir son contenu à l'aide de JavaScript.
Un ensemble complet d'exemples de service workers est disponible dans les exemples Google Chrome. Le livre de recettes hors connexion de Jake Archibald est un incontournable. Je vous recommande vivement d'essayer le tutoriel de Paul Kinlan sur votre première application Web hors connexion si vous débutez avec les service workers.
Notre équipe gère également un certain nombre d'utilitaires d'aide et d'outils de compilation pour les service workers, que nous trouvons utiles pour réduire la surcharge liée à la configuration des service workers. Elles sont répertoriées sur la page Bibliothèques de service workers. Voici les deux principaux :
- sw-precache : outil de compilation qui génère un script de service worker utile pour pré-mettre en cache le shell d'application Web.
- sw-toolbox : bibliothèque fournissant une mise en cache d'exécution pour les ressources rarement utilisées.
Jeff Posnick a rédigé un guide d'introduction rapide sur sw-precache intitulé Offline-first, fast, with the sw-precache module (Hors connexion d'abord, rapidement, avec le module sw-precache) et un atelier de programmation sur le même outil, qui pourraient vous être utiles.
Chrome, Opera et Firefox ont tous implémenté la prise en charge des service workers, et Edge a émis des signaux publics positifs quant à son intérêt pour cette fonctionnalité. Safari a brièvement mentionné son intérêt pour cette fonctionnalité dans le plan quinquennal proposé par l'un de ses ingénieurs.
Notifications push pour le réengagement
En effet, vous pouvez créer des applications Web avec lesquelles les utilisateurs peuvent interagir en dehors d'un onglet. Le navigateur peut être fermé, et les utilisateurs n'ont même pas besoin d'utiliser activement votre application Web pour interagir avec votre expérience. Cette fonctionnalité nécessite à la fois un service worker et un fichier manifeste d'application Web, en s'appuyant sur certaines des fonctionnalités résumées précédemment.
L'API Push est implémentée dans Chrome, en cours de développement dans Firefox et en cours d'examen dans Edge. Safari n'a pas encore indiqué publiquement son intention d'implémenter cette fonctionnalité.
Push Notifications on the Open Web est une introduction complète à la configuration des notifications push par Matt Gaunt. Un atelier de programmation sur les notifications push est également disponible sur Web Fundamentals.
Michael van Ouwerkerk, de l'équipe Chrome, propose également une introduction de six minutes à Push si vous préférez les vidéos.
Ajouter des fonctionnalités avancées
N'oubliez pas que l'expérience utilisateur peut varier en fonction du navigateur utilisé pour afficher votre application Web. Vous contrôlez la coque de bonbon dur.
D'autres fonctionnalités de la plate-forme Web, telles que la synchronisation en arrière-plan (pour synchroniser les données avec un serveur même lorsque votre application Web est fermée) et Web Bluetooth (pour communiquer avec des appareils Bluetooth depuis votre application Web), peuvent également être intégrées à votre progressive web app de cette manière.
La synchronisation en arrière-plan ponctuelle a été activée dans Chrome. Jake Archibald a publié une vidéo de son application Wikipédia hors connexion et un article qui en montre le fonctionnement. François Beaufort propose également un certain nombre d'exemples Web Bluetooth si vous souhaitez essayer cette API.
Compatibilité avec les frameworks
Rien ne vous empêche d'appliquer les principes ci-dessus à une application ou à un framework existant que vous utilisez. Voici quelques autres principes à garder à l'esprit lors de la création de votre progressive web app : le modèle de performances centré sur l'utilisateur RAIL et les animations basées sur FLIP.
J'espère qu'en 2016, nous verrons un nombre croissant de modèles et de projets de départ intégrer de manière organique la prise en charge des progressive web apps en tant que fonctionnalité essentielle. En attendant, l'ajout de ces fonctionnalités à vos propres applications n'est pas très difficile et, à mon avis, en vaut la peine.
Architecture
Il existe différents niveaux d'intégration du modèle de progressive web app, mais une approche courante consiste à les architecturer autour d'un shell d'application. Il ne s'agit pas d'une exigence stricte, mais cela présente plusieurs avantages.
L'architecture de shell d'application encourage la mise en cache de votre shell d'application (l'interface utilisateur) afin qu'il fonctionne hors connexion et qu'il remplisse son contenu à l'aide de JavaScript. Lors des visites répétées, cela vous permet d'obtenir des pixels significatifs à l'écran très rapidement sans le réseau, même si votre contenu provient finalement de là. Cela s'accompagne d'une amélioration significative des performances.
Jeremy Keith a récemment indiqué que, dans ce type de modèle, l'affichage côté serveur ne devrait peut-être pas être considéré comme une solution de remplacement, mais que l'affichage côté client devrait être considéré comme une amélioration. C'est un commentaire pertinent.
Dans le modèle de shell d'application, le rendu côté serveur doit être utilisé autant que possible, et le rendu progressif côté client doit être utilisé comme une amélioration, de la même manière que nous "améliorons" l'expérience lorsque le service worker est pris en charge. Il existe de nombreuses façons d'aborder ce problème.
Je vous recommande de lire notre article sur l'architecture et d'évaluer comment des principes similaires pourraient être appliqués au mieux à votre propre application et à votre pile.
Modèles de démarrage
Shell d'application
Le dépôt app-shell contient une implémentation presque complète de l'architecture de shell d'application. Elle dispose d'un backend écrit en Express.js et d'une interface écrite en ES2015.
Étant donné qu'il couvre à la fois les parties client et côté serveur du modèle et qu'il s'y passe beaucoup de choses, il vous faudra un certain temps pour vous familiariser avec la codebase. Il s'agit actuellement de notre point de départ le plus complet pour les progressive web apps. Nous allons maintenant nous concentrer sur Docs pour ce projet.
Kit de démarrage Polymer
Le point de départ officiel des applications Web Polymer est compatible avec les fonctionnalités de progressive web app suivantes :
- Fichier manifeste d'application Web
- Écran de démarrage de Chrome pour Android
- Mise en cache hors connexion du service worker avec les éléments Platinum SW
- Notifications push (configuration manuelle requise) avec les éléments Platinum Push
La version actuelle de PSK ne prend pas en charge certains des modèles de performances les plus avancés (par exemple, le modèle de shell d'application, le chargement asynchrone) que vous trouvez dans certaines applications Web Progressive Polymer.
Nous prévoyons d'intégrer ces modèles à PSK en 2016, mais vous trouverez des tests préliminaires dans l'application Polymer Zuperkulblog de Rob Dodson et dans l'excellente présentation Polymer Perf Patterns d'Eric Bidelman.
Web Starter Kit
Notre point de départ pour les nouveaux projets Vanilla inclut les fonctionnalités de progressive web app suivantes :
- Fichier manifeste d'application Web
- Écran de démarrage de Chrome pour Android
- Mise en cache préalable du service worker grâce à sw-precache
Si vous préférez travailler avec vanilla JS/ES2015 et que vous ne pouvez pas utiliser Polymer, Web Starter Kit peut s'avérer utile en tant que point de référence que vous pouvez réutiliser ou dont vous pouvez extraire des extraits de code.
Progressive Web Apps avec et sans frameworks
Plusieurs progressive web apps Open Source ont déjà été créées par des membres de la communauté, avec ou sans bibliothèques et frameworks JS. Si vous cherchez l'inspiration, les dépôts ci-dessous peuvent vous être utiles. Ce sont aussi d'excellentes applications.
Vanilla JavaScript
- Voice Memos de Paul Lewis est conçu à l'aide d'une architecture similaire à
app-shell(article). - Wikipédia hors connexion par Jake Archibald (vidéo)
- Air Horner par Paul Kinlan
- Guitar Tuner par Paul Lewis (article)
Polymer
- Zuperkulblog par Rob Dodson (diapositives)
Réagir
- iFixit par Jeff Posnick : utilise
sw-precachepour la mise en cache du shell d'application (diapositives)
DOM virtuel
- Pokedex par Nolan Lawson : excellente progressive web app appliquant une approche "tout faire dans un Web Worker" pour faciliter l'affichage progressif. (write-up)
Angular.js
- Timey.in de Kenneth Auchenberg utilise également
sw-precachepour la mise en cache préalable des ressources.
Notes de fermeture
Comme nous l'avons mentionné, les progressive web apps n'en sont qu'à leurs débuts, mais il est intéressant de tester les méthodologies qui les sous-tendent et de voir comment elles peuvent s'appliquer à vos propres applications Web.
Paul Kinlan est actuellement en train de planifier les conseils de Web Fundamentals sur les progressive web apps. Si vous avez des suggestions sur les domaines que vous aimeriez voir abordés, n'hésitez pas à les ajouter au fil de discussion.
Documentation complémentaire
- Progressive Web Apps: Escaping Tabs Without Losing Our Soul
- Why Progressive Web Apps Are The Future Of Web Development
- Progressive Web Apps: ready for primetime
- Créer une progressive web app avec ServiceWorker
- Progressive Web Apps Are the Future
- Progressive Web App: A New Way to Experience Mobile
- Présentation de Pokedex.org : une progressive web app pour les fans de Pokémon
- Récapitulatif du Chrome Developer Summit : Progressive Web Apps