Progressive Web Apps (PWA)

De Jérôme Meillant dans Technique

9 fév 2017

 

Qu’est ce que c’est ?

Les Progressive Web Apps (PWA) sont une petite révolution dans le monde du mobile !
Elles mixent en fait deux mondes, celui du Web et celui des applications mobiles.
Il s’agit en fait d’une application Web proposant les fonctionnalités habituelles des applications mobiles (icon pour lancer l’application, accessible en mode déconnecté, gestion des notifications, …).

Dans les faits il suffit d’utiliser un navigateur Web pour accéder à l’application PWA, le navigateur va alors nous indiquer que l’application est disponible en mode hors ligne et il va nous offrir la possibilité de l’ajouter sur la page d’accueil de notre device mobile.
Lorsqu’on accepte, un icon apparaît sur la page d’accueil.
La sélection de l’icon lance l’application, même si le device est hors connexion.
L’application a le même visuel que lorsqu’on était dans le navigateur Web sauf qu’elle s’affiche en mode plein écran.

Voici un exemple simple permettant de comprendre le principe : https://pokedex.org

Pokedex Web    Pokedex Web 2

Ajout de la PWA sur le device

Pokedex desktop icon    Pokedex PWA

Lancement de la PWA depuis l’écran d’accueil du device

Cette révolution a été introduite par Google en juin 2015 : https://infrequently.org/2015/06/progressive-apps-escaping-tabs-without-losing-our-soul/

Elle s’appuie sur les futurs standards du W3C :

Gestion du mode off line et des lenteurs du réseau via un script JavaScript qui s’exécute en arrière-plan dans un thread indépendant ; le Service Worker reçoit un événement dès qu’une page du site fait une requête HTTP, on a donc la main pour renvoyer la réponse de notre choix (récupération de données distantes ou stockés sur le device).
Il s’appuie sur deux API : “Fetch” (récupération du contenu à partir du réseau) et “Cache” (stockage des données dans un cache indépendant du navigateur).

Ce service ouvre beaucoup de possibilités :) par exemple la “Push API” (https://www.w3.org/TR/push-api/) envoie un événement au Service Worker lorsqu’un message push est envoyé ; l’événement peut alors déclencher ce que l’on souhaite, par exemple la mise à jour du cache de la PWA.
Dans l’avenir on pourra même envisager des interactions entre les PWA et les objets connectés grâce par exemple à la spécification W3C en cours sur le “Web Bluetooth” : https://webbluetoothcg.github.io/web-bluetooth/

Spécification définissant un fichier de manifest pour centraliser des métadonnées associées à l’application Web ; on y retrouve notamment l’icon de l’application, son nom, l’url appelée et le splashscreen à afficher au lancement de l’application, le mode d’orientation de l’écran …

API permettant d’afficher des notifications sur le device pour alerter les utilisateurs même lorsqu’ils ne sont pas sur l’application Web.

 

D’accord mais quel est l’intérêt par rapport à un site Web ou à une application mobile ?

Mieux qu’un site Web :

  • Accessible depuis l’écran d’accueil du device comme une application mobile classique grâce au fichier “Web App Manifest”.
  • Affichage en plein écran, sans la barre de navigation du navigateur Web.
  • Pas besoin de réseau pour utiliser l’application : les éléments graphiques qui bougent très peu sont stockés sur le device lors de la première utilisation de l’application, la synchronisation des données a lieu dès le retour du réseau.

Mieux qu’une application mobile :

  • Pas besoin de pousser l’application sur les stores.
  • Pas d’installation pour l’utilisateur.
  • Très performant (un cache dédié permet de stocker des éléments comme par exemple les éléments graphiques permettant un affichage instantané, même hors ligne).
  • Un seul code source pour tous les types de devices contrairement aux applications natives.
  • Référencé par les moteurs de recherche Web.

 

Super mais j’imagine qu’il y a des contraintes ?

  • Technologie qui s’appuie sur des spécifications du W3C en Working Draft (non finalisées).
  • Les PWA doivent être en https (les navigateurs imposent que le site soit sécurisé car le Service Worker renvoie des réponses en provenance du réseau ou d’un cache dédié).
  • Pour l’instant seul les navigateurs Chrome, Firefox et Opéra prennent en charge les PWA (pas de date communiquée pour IE/Edge et Safari).

Microsoft utilise néanmoins déjà certains principes des PWA permettant de transformer un site Web en application Windows universelle (publiable sur le Windows Store) appelée “Hosted Web App” (HWA) :

https://developer.microsoft.com/en-us/windows/bridges/hosted-web-apps

https://msdn.microsoft.com/en-us/windows/uwp/porting/hwa-create-windows

On peut voir sur le site developer de Microsoft qu’ils travaillent actuellement sur l’intégration dans Edge des spécifications sur lesquelles s’appuient les PWA :

https://developer.microsoft.com/en-us/microsoft-edge/platform/status/serviceworker/

https://developer.microsoft.com/en-us/microsoft-edge/platform/status/webapplicationmanifest/

https://developer.microsoft.com/en-us/microsoft-edge/platform/status/pushapi/

Du côté iOS, Safari intègre depuis le 22 août 2016 la “Fetch API” (une API sur laquelle s’appuie le Service Workers ; le Service Workers est toujours aujourd’hui qualifié en “Under Consideration” au niveau de WebKit).

 

Et côté développement ?

Google a créé des librairies pour faciliter l’utilisation du Service Worker :

https://developers.google.com/web/tools/service-worker-libraries/

Notamment “sw-precache” pour générer un Service Worker qui met en cache les ressources de l’application et “sw-toolbox” qui fournit des helpers pour utiliser et créer un Service Worker.

Exemple de code que l’on peut utiliser dans le JS de notre Service Worker :

   toolbox.router.get('/(.*)', global.toolbox.cacheFirst, {
      cache: {
         name: 'googleapis',
         maxEntries: 10,
         maxAgeSeconds: 86400
      },
      origin: /\.googleapis\.com$/
   });

Ce code permet d’intercepter l’ensemble des requêtes HTTP qui ont pour origine “googleapis.com” pour les stocker dans le cache, nommé “googleapis”, de notre Service Worker.
Le cache “googleapis” est limité à 10 éléments et expire au bout de 86400 secondes.
La méthode “cacheFirst” permet de récupérer le résultat dans le cache si l’entrée correspondante y est présente sinon il fait un appel sur le réseau.

Google fourni également des outils dans Chrome.

L’onglet “Application” permet de voir le contenu du “Manifest”, de lister les Service Workers de l’application, d’accéder au cache du Service Worker …

Pokedex Chrome

On peut par exemple lister et lancer/arrêter tous les Service Workers installés dans Chrome via cette url : chrome://serviceworker-internals/

Chrome Service Workers

Actuellement les Frameworks Web n’intègrent que très peu ces spécifications.

Pour construire une PWA on peut utiliser Polymer, la librairie JS de Google qui permet de créer des applications Web basées sur les Web components.
Elle dispose d’une toolbox “Polymer App Toolbox” (collection de composants, outils et templates) permettant de créer des PWA et d’utiliser le Service Worker : https://www.polymer-project.org/1.0/start/toolbox/set-up

On peut néanmoins créer une application avec notre Framework habituel en intégrant les librairies de Google ; par exemple ce projet React : https://github.com/localnerve/react-pwa-reference
Côté Angular, Ionic a également annoncé fin 2016 la génération de PWA en plus de la génération d’applications mobiles natives : http://blog.ionic.io/announcing-pwa-support-in-ionic-2/

Voici un article décrivant comment réaliser une PWA :
http://blog.eleven-labs.com/fr/votre-premiere-pwa/

Google fourni un outil d’analyse concernant les PWA, on lui indique l’url du site Web et il génère un rapport sur les différentes fonctionnalités “PWA” du site :
https://developers.google.com/web/tools/lighthouse/

 

Conclusion

Les PWA sont des applications Web offrant les avantages des applications mobiles.
Cette technologie s’appuie sur des standards très prometteurs mais qui sont toujours en cours de spécification par le W3C.
Les navigateurs Web et l’outillage côté développements commencent tout juste à intégrer ces futurs standards, il va donc falloir attendre un peu pour voir cette technologie se répandre.

Tout amène à penser que les PWA sont l’avenir des applications Web car elles répondent aux problématiques dans “l’air du temps” : nomadisme, interconnexion avec des systèmes tiers, facilité de mise en place et d’accès.
On peut également remarquer que tous les acteurs du domaine communiquent sur le sujet et intègrent les éléments permettant la réalisation et l’utilisation de PWA.
Sujet à suivre de près !!

 

1 Réponse pour Progressive Web Apps (PWA)

Avatar

Cyril K

février 10th, 2017 à 10 h 16 min

Merci pour cet article !

ci dessous un article également intéressant sur le REXP du developpement d’une PWA

https://14islands.com/blog/2017/01/19/progressive-web-app-from-scratch/

Commentaire

trois + = 9

iMDEO recrute !

REJOIGNEZ-NOUS

A la recherche de nouveaux talents (développeurs web et mobile, chefs de projet,...)

Voir les annonces