Prérequis

Introduction

Avant d’aborder les différentes API derrière le terme Progressive Web App, il est important de définir les prérequis que nous devons respecter dans une application. Sans cette étape, nous risquons de créer une Progressive Web App non optimale pour un usage sur mobile, voire pas fonctionnelle du tout. Pour rappel, une Progressive Web App a pour but de se rapprocher au maximum de l’expérience utilisateur d’une application native. Afin d’y arriver, quelques bonnes pratiques doivent être respectées.

La plupart de ces bonnes pratiques ne sont pas réservées aux Progressive Web Apps, mais sont plutôt des règles que nous devons suivre lors de nos différents développements web.

Responsive Web Design

Pour rendre une application web mobile compatible Progressive Web App, la première chose à faire est de s’assurer que le contenu du site est optimisé pour les différentes tailles d’écran des utilisateurs : ordinateur, téléphone, tablette, TV...

L’une des premières solutions est de créer deux versions de l’application : une pour les grands écrans (ordinateur, TV…) et une autre pour les téléphones et tablettes. Avec une configuration côté serveur permettant de rediriger vers la bonne version en fonction des caractéristiques de l’utilisateur, nous avons deux versions du site optimisées chacune pour sa plateforme cible. Qui n’a jamais utilisé un site ayant ce genre d’architecture avec des URL ressemblant à http://ma-societe.fr et http://mobile.ma-societe.fr ? Mais bien évidemment, cette duplication complexifie la maintenance des applications, en demandant aux développeurs de faire des modifications sur les deux versions à chaque fonctionnalité ou correctif implémenté. C’est une solution que nous ne recommandons pas, bien évidemment.

Nous préférons garder une et une seule version de l’application et la rendre utilisable sur les différents écrans. Nous allons donc la rendre responsive.

1. Définition du viewport

La première étape consiste à ajouter une balise meta dans la partie head du site. Cette balise meta permet de configurer le viewport, objet correspondant à ce qui est physiquement visible sur l’écran.

<html> 
   <head> 
     <meta name="viewport" ... /> 
   </head> 
</html>

Pour cette balise, nous pouvons définir différents paramètres : width, height, initial-scale, maximum-scale, minimum-scale ou encore...

Outils d’aide aux développement d’application web mobile

Pour nous assurer que notre application est fonctionnelle pour des tailles différentes d’écran, nous pouvons utiliser les outils proposés par notre navigateur de prédilection.

La plupart des navigateurs proposent à présent dans leurs outils d’aide au développement, un moyen de visualiser l’application en spécifiant la résolution de l’écran, son orientation, le DPR (Device Pixel Ratio) ou encore la vitesse du réseau (3G, Wi-Fi…). Grâce à cette solution, nous pouvons rapidement voir si le site est utilisable sur le parc des écrans que nous devons supporter.

Voici par exemple cette fonctionnalité sur Firefox, puis sur Chrome.

Outils disponibles dans Chrome permettant d’émuler des tailles d’écran différentes

Outils disponibles dans Firefox permettant d’émuler des tailles d’écran différentes

Il est possible de mettre en place des tests automatisés permettant de s’assurer qu’aucune régression en termes de design n’est ajoutée dans l’application. La plupart des solutions actuelles permettent de modifier la taille du viewport du navigateur utilisé dans les tests.

Ci-après, nous définissons la taille du viewport dans des tests basés...

Performances

Les utilisateurs d‘applications natives sont habitués à des applications performantes, dont le lancement et l’affichage du contenu sont quasi instantanés. En effet, tout le code qui est nécessaire est déjà présent sur le téléphone et ne nécessite donc pas de nouveau téléchargement, comme pour une application web.

Nous devons nous rapprocher au maximum de cette expérience avec notre Progressive Web App. En plus de l’expérience utilisateur qui sera améliorée, le fait de déployer une Progressive Web App performante sera bénéfique pour l’utilisation de la batterie du téléphone des utilisateurs.

Voici une liste non exhaustive des bonnes pratiques que nous pouvons mettre en place lors de nos prochains développements. La plupart d’entre elles sont également applicables aux applications web en général. Le chapitre Performances générales sera dédié à cette problématique.

1. Optimisation de la taille des livrables

La première chose à faire est de réduire la taille des fichiers statiques via l’utilisation d’outils comme Rollup, Google Closure, Terser ou encore Webpack. Afin d’y arriver, voici les actions à mettre en œuvre via la plupart des outils de build du marché.

minification : suppression de tous les caractères non nécessaires pour l’exécution de l’application en production (sauts de ligne, commentaires...).
bundler : regroupement fonctionnel ou technique de plusieurs fichiers JavaScript en un seul.
tree shaking : suppression du code non nécessaire au bon fonctionnement de l’application en production (dead code elimination).

L’exemple ci-après permet de générer le livrable d’une application en utilisant Webpack, l’outil open source le plus utilisé pour optimiser des Single Page Applications. En une dizaine de lignes de code, nous allons appliquer les bonnes pratiques citées précédemment. Nous mettons tout le contenu de src/index.js ainsi que des fichiers JavaScript qu’il importe dans un fichier dist/bundle.js. Et grâce au paramètre mode, nous activons la minification et le tree shaking....

HTTPS

Même si cela devient une obligation pour l’ensemble des applications souhaitant être référencées de manière optimale par les moteurs de recherche, nous préférons indiquer que les fonctionnalités présentées dans cet ouvrage ne sont disponibles que si l’application est servie via une connexion sécurisée, utilisant le protocole HTTPS (HyperText Transfer Protocol Secure).

Au chapitre Service Worker, nous allons aborder l’API des Service Workers. Pour faire simple, cette API permet de définir un proxy entre notre navigateur et le réseau. Cela signifie que ce proxy intercepte toutes les requêtes sortantes afin d’en faire éventuellement un traitement. Utiliser cette fonctionnalité sur une connexion non sécurisée est très dangereux pour les utilisateurs. C’est une source d’éventuelles attaques de type man in the middle ou XSS (Cross-Site Scripting), pouvant modifier le contenu du Service Worker, afin d’intercepter toutes les requêtes pour les aiguiller vers un serveur tiers.

De plus en plus de solutions proposent l’hébergement des ressources statiques sur un serveur configuré pour utiliser une connexion sécurisée : GitHub Pages (https://pages.github.com/), Netlify (https://www.netlify.com/), Firebase Hosting...

Auditer une application

Avant de commencer à modifier une application pour la rendre compatible avec les API des Progressive Web Apps, il est intéressant de faire un audit de son état actuel. Pour cela, nous allons utiliser le projet créé par Google : Lighthouse. Cet outil peut être utilisé de plusieurs façons : via le navigateur Chrome, en ligne de commande ou encore via Lighthouse CI.

Lighthouse est tout d’abord un outil intégré au DevTools de Chrome (onglet Audits). Il permet d’auditer une application sur plusieurs critères : Performance, Progressive Web App, Best practices, Accessibility, SEO.

Interface de Lighthouse permettant de sélectionner le type d’audit souhaité

Nous pouvons sélectionner les options qui nous intéressent et lancer un audit. Après quelques secondes, Lighthouse propose un rapport complet. Pour chaque critère, il indique une note sur 100, ainsi que les points que nous pouvons améliorer.

Seul le critère Progressive Web App ne possède pas de note sur 100, car l’équipe de Lighthouse a décidé de le découper en trois sous-catégories : Fast and reliable, Installable et PWA Optimized. Dans le résultat ci-après, nous pouvons voir notamment que l’URL configurée dans le fichier Manifest (voir le chapitre...

Application fil rouge

Avant de commencer les nouveaux développements sur l’application fil rouge, nous allons l’auditer grâce à Lighthouse. Pour cela, ouvrons de nouveau l’application depuis Chrome, et depuis l’onglet Audit, lançons un nouvel audit.

Le rapport d’audit s’affiche avec toutes les tâches que nous pouvons réaliser afin d’optimiser le site.

Par exemple, pour les critères liés aux Progressive Web Apps, voici ce que nous pouvons améliorer :

Rapport d’audit de notre application

Lighthouse préconise de faire servir l’application par une connexion sécurisée. Lorsque nous sommes en phase de développement, nous n’avons pas nécessairement envie de mettre en place une connexion TLS (Transport Layer Security). C’est pour cela qu’il est préférable de faire ces phases d’audit sur un environnement proche de celui de production.

Si nous imaginons le mettre en place dans notre solution d’intégration continue, il faudra donc déployer l’application sur un serveur proche en termes de configuration technique du serveur de production, et ensuite lancer l’audit Lighthouse.

Afin de résoudre ce problème de connexion TLS, nous allons déployer l’application sur Netlify, qui propose par défaut et gratuitement cette fonctionnalité....