PWA : qu'est-ce que c'est et comment soigner la performance au quotidien

Une Progressive Web App promet le meilleur des deux mondes : l’accessibilité du Web avec la sensation d’une application installée. Il s'ouvre rapidement, fonctionne hors ligne, peut envoyer des notifications, s'installe sur l'écran d'accueil sans se rendre dans un magasin. En théorie, c'est élégant.

Beaucoup de gens allument une PWA, voient qu'elle « fonctionne » et supposent qu'ils ont obtenu des performances gratuites. Quelques mois plus tard, l'application est lente, le cache est plus un obstacle qu'une aide, et l'expérience de l'application est devenue une page Web lourde avec une icône à l'écran.

PWA n'est pas un commutateur de performances. C’est une architecture qui, si elle est bien entretenue, génère de la vitesse, et qui, négligée, génère de la frustration. Je veux vous expliquer ce qu'est un PWA et, surtout, comment maintenir une bonne performance dans votre routine, car c'est au quotidien que l'on gagne ou perd.

Qu'est-ce qu'une PWA, pas de mystère

Une PWA est, par essence, un site Web qui utilise un ensemble de technologies Web modernes pour se comporter comme une application. Les trois piliers sont le service worker, qui s'exécute en arrière-plan et contrôle la mise en cache et le fonctionnement hors ligne ; le manifeste, qui vous permet d'installer l'application sur l'écran d'accueil avec sa propre icône et son propre nom ; et l'utilisation du HTTPS, une exigence de sécurité pour que tout cela fonctionne.

Le travailleur des services est au cœur de l'histoire. Il se situe entre l'application et le réseau, interceptant les requêtes et décidant ce qu'il faut servir à partir du cache et ce qu'il faut récupérer en ligne. C'est ce qui fait que la PWA s'ouvre instantanément et fonctionne sans connexion.

Ce pouvoir est aussi source de problèmes. Un service worker mal configuré sert du contenu ancien, ne se met pas à jour quand il le devrait ou remplit l'appareil avec un cache inutile. La même partie qui vous donne de la vitesse peut vous donner de la lenteur.

La thèse : les performances des PWA sont une question de maintenance, pas d'installation

L'idée que je veux le plus combattre est que la performance vient de la décision « d'utiliser PWA ». Je soutiens que cela vient d’habitudes de développement continu et qu’une PWA nécessite plus de discipline, pas moins, qu’un site Web classique.

La raison est simple : PWA ajoute une couche, le service worker et ses stratégies de mise en cache, qui doit être pensée, testée et maintenue. Chaque nouvelle version de l'application est l'occasion de casser le cache, de diffuser du contenu obsolète ou de gonfler ce qui est stocké sur l'appareil.

Par conséquent, la performance de PWA est un soin de routine. C'est quelque chose qui entre dans le flux de chaque livraison, pas une configuration que vous effectuez une seule fois et que vous oubliez. Ceux qui le considèrent comme oubliable accumulent des problèmes qui n'apparaissent que lorsque l'utilisateur est déjà irrité.

Stratégie de mise en cache : le soin central

La décision la plus importante dans une routine PWA est la façon dont chaque type de ressource est mis en cache. Il n’existe pas de stratégie unique qui soit bonne pour tout.

Les fichiers qui changent rarement, le code d'application, les icônes, les polices, peuvent être mis en cache de manière agressive, servis d'abord depuis le cache pour s'ouvrir rapidement. Les données qui changent tout le temps, le contenu que l'utilisateur consomme, nécessitent des stratégies qui priorisent le réseau ou qui valident si le cache est encore frais.

L’erreur la plus courante consiste à appliquer une stratégie agressive à tout. L'application s'ouvre rapidement, mais affiche des informations anciennes et l'utilisateur voit des prix, un statut ou un contenu obsolètes. Dans les applications contenant des données sensibles, cela passe d’une nuisance à un problème sérieux.

Au quotidien, chaque nouvelle fonctionnalité ajoutée à l’application doit soulever la question : comment la mettre en cache ? Traiter cette question comme faisant partie du développement, et non comme un détail, est ce qui unit performance et exactitude.

Versionnement et mise à jour indolores

Un problème classique de PWA est que l'utilisateur reste bloqué sur une ancienne version parce que le service worker continue de servir l'ancien cache. Vous publiez une correction et l'utilisateur ne la voit pas, car son application insiste pour afficher ce qu'il a enregistré.

La résolution de ce problème nécessite une stratégie de gestion des versions du cache et de mise à jour des techniciens de service. Lorsqu'une nouvelle version est publiée, l'application doit remarquer, télécharger le nouveau contenu et l'activer de manière contrôlée, idéalement en informant l'utilisateur ou en le mettant à jour à sa prochaine ouverture.

Ce flux doit être testé à chaque livraison. J'ai vu des équipes publier des correctifs urgents qui ne parvenaient tout simplement pas aux utilisateurs en raison d'un cache mal géré. Le correctif existait sur le serveur et était inutile sur l'appareil. Les performances incluent ici la possibilité d’appliquer rapidement des correctifs, et cela dépend du fonctionnement du cycle de mise à jour.

Mesurer fait partie de la routine

Vous ne pouvez pas vous occuper de ce que vous ne mesurez pas. Les performances d'une PWA doivent être surveillées avec des données réelles, pas seulement avec l'impression que « c'est rapide sur ma machine ».

Les outils d'audit des performances Web aident à mesurer le temps de chargement, la taille des ressources et la qualité des opérations hors ligne. Les mesures de charge perçues, la rapidité avec laquelle l'utilisateur voit quelque chose d'utile à l'écran, en disent plus sur l'expérience que des chiffres techniques isolés.

L’idéal est d’incorporer cette mesure dans le flux de livraison, afin que les régressions de performances soient détectées avant qu’elles n’atteignent l’utilisateur. Une application rapide et ralentie s'aggrave rarement d'un seul coup ; Cela s’est aggravé petit à petit, avec des livraisons que personne n’a mesurées. La mesure continue est ce qui transforme la performance du hasard en contrôle.

Les limites et les pièges de la PWA

Autant je défends la PWA, autant il est important d’en reconnaître les limites pour ne pas vendre d’illusion. Dans certains systèmes, l'accès aux ressources de l'appareil est encore plus restreint que dans une application native. Les notifications et le comportement d'installation varient selon les plates-formes. Et il existe des fonctionnalités matérielles qu’une PWA n’atteint tout simplement pas dans la même profondeur.

De plus, la flexibilité du Web lui-même peut conduire à des applications volumineuses. Sans discipline, il est facile d'accumuler des bibliothèques, des scripts et des styles qui alourdissent la charge. PWA ne corrige pas les mauvais codes ; cela ajoute simplement une couche par-dessus. Les mauvaises performances à la base continuent d'être mauvaises avec la PWA activée.

Le plus gros piège est la complaisance. Parce que la PWA « ressemble » à une application et s'ouvre rapidement après le premier chargement, il est facile d'arrêter de mesurer et de s'en soucier. La dégradation arrive silencieusement, et lorsque quelqu'un s'en aperçoit, la récupération des performances coûte plus cher que ce qu'il aurait coûté pour les maintenir.

PWA est une excellente technologie pour tous ceux qui souhaitent une portée Web de qualité applicative, à condition qu'ils comprennent que cette qualité est le résultat d'un soin continu. La vitesse du premier jour ne demeure que s’il y a de la discipline chaque jour.

Si votre équipe maintient une PWA et souhaite structurer une routine de suivi de la performance, il existe d'autres textes ici sur le blog sur le web, la performance et le développement. Et si vous souhaitez parler de votre produit, je suis à votre disposition.