PWA vs natif en pratique : comment offrir des performances dans chacun

La discussion « PWA ou natif » se termine au moment de la décision pour la plupart des articles. Mais pour ceux qui construisent, la décision n’est qu’un début. Choisir la bonne plateforme et la mal exécuter donne le même résultat que choisir la mauvaise : un produit lent que l’utilisateur abandonne.

J'ai vu des PWA rapides et des PWA très lentes. J'ai vu des applications natives fluides et des applications natives bloquées. La plateforme ne garantit pas les performances ; garanties d'exécution. Et chaque approche a ses propres points d’échec, ses propres pièges et ses propres pratiques de soins.

Ce texte s’adresse à ceux qui ont déjà décidé et qui doivent maintenant se prononcer. Au lieu de comparer PWA et natif dans l'abstrait, j'aborderai comment maintenir les performances de chacun dans la pratique, où chacun a tendance à rester bloqué et que faire pour que la vitesse atteigne l'utilisateur et reste.

La performance est ce que ressent l'utilisateur, pas ce que montre le graphique

Avant toute technique, il convient d’aligner ce qui compte. La performance, pour l’utilisateur, n’est pas un chiffre de référence. C'est le sentiment que l'application répond. Il s'agit de voir rapidement quelque chose d'utile, de le toucher et d'obtenir une réponse, sans attendre avec l'écran figé.

Cette distinction change notre façon de travailler. Optimiser des métriques internes que l'utilisateur ne remarque pas est un gaspillage. L'optimisation du temps jusqu'à la première interaction utile, la fluidité des réponses et l'absence de crash, c'est ce qui retient.

Dans PWA et natif, la règle est la perception. Les techniques changent, mais l'objectif est le même : que le produit apparaisse rapidement là où l'utilisateur regarde. Celui qui recherche cela, et non le joli chiffre, obtient de meilleurs résultats.

En pratique, délivrer des performances dans une PWA

Le talon d’Achille de PWA est le poids de la toile. Lorsqu'il s'exécute dans le navigateur, tout ce que vous chargez, scripts, styles, bibliothèques, a des conséquences néfastes sur l'heure d'ouverture. L’erreur la plus courante consiste à accumuler des dépendances jusqu’à ce que l’application ralentisse sans que personne ne se rende compte du moment où cela s’est produit.

La première pratique consiste à garder l’application légère. Chargez uniquement ce qui est nécessaire pour le premier écran et reportez le reste. Cassez le code pour que l'utilisateur ne télécharge pas d'un coup ce qu'il n'utilisera que plus tard. Chaque kilo-octet coupé de la charge initiale apparaît comme vitesse perçue.

La seconde consiste à maîtriser le cache du service worker. C'est ce qui fait que PWA s'ouvre instantanément lors des visites ultérieures et fonctionne hors ligne. Mais un cache mal configuré sert l’ancien contenu ou empêche l’arrivée des mises à jour. En pratique, définir des stratégies par type de ressource, agressives pour ce qui ne change pas, validées pour ce qui change, et tester la mise à jour à chaque livraison, afin de ne pas enfermer l'utilisateur dans une ancienne version.

La troisième est de mesurer avec des données réelles et dans des conditions réelles : connexion lente, appareil modeste. Ce qui vole sur la machine du développeur peut ramper sur le téléphone portable de l'utilisateur. Les performances de PWA sont maintenues lorsque la mesure entre dans le flux de diffusion, et non lorsque l'on s'appuie sur l'impression.

En pratique, délivrer des performances de manière native

Native présente un avantage brut en termes de performances, mais cela crée un faux sentiment de sécurité. Le piège ici n'est pas le poids du chargement, mais l'utilisation imprudente des ressources de l'appareil : mémoire, batterie, travail sur le thread principal.

La première pratique est de protéger la fluidité de l’interface. En natif, toute opération lourde effectuée dans le thread qui dessine l'écran provoque un crash visible. Les travaux lourds, le traitement, l'accès aux données, la mise en réseau doivent quitter ce fil pour que l'interface continue de répondre. Les plantages de défilement et de tapotement viennent presque toujours d’ici.

La seconde est de prendre soin de la mémoire et des ressources. Les applications natives qui fuient de la mémoire ou monopolisent des ressources se dégradent avec l'utilisation, devenant plus lentes à mesure qu'elles restent ouvertes. En pratique, cela nécessite de la discipline dans la publication de ce qui n’est pas utilisé et dans le test de l’application lors de longues sessions, et pas seulement lors de lancements rapides.

La troisième est de respecter le dispositif. Une consommation excessive de batterie et de données n'apparaît pas dans un court test, mais elle détruit la réputation de l'application en utilisation réelle et conduit à une désinstallation. Mesurer le comportement de l'application au fil du temps, sur différents appareils, est ce qui différencie le natif qui semble bon dans la démo du natif qui maintient la qualité dans la vie de l'utilisateur.

L'erreur qui les coule tous les deux

Il existe un piège commun aux deux approches, et il est culturel avant d'être technique : laisser la performance jusqu'au bout.

Les équipes qui considèrent la vitesse comme un ajustement final, une fois le produit prêt, découvrent que les mauvaises performances résident généralement dans l'architecture et non dans les détails. On ne peut pas « optimiser plus tard » ce qui a été construit sans penser à la rapidité. Les gains de dernière minute sont faibles ; les problèmes structurels sont importants.

La pratique qui évite cela consiste à intégrer la performance comme critère continu. Mesurez tôt, établissez un plafond de charge et de réponse acceptable et traitez la régression des performances comme un défaut et non comme une amélioration facultative. En PWA comme en natif, la vitesse qui reste est celle qui a été prise en charge dès le début, livraison après livraison.

Une autre erreur commune est de ne pas mesurer en conditions réelles. L'appareil de développement est puissant et dispose d'un bon réseau. Pas l'utilisateur. Une performance qui n’existe que dans l’environnement de ceux qui la construisent est une illusion.

La performance comme discipline, pas comme miracle

La leçon qui s'applique aux PWA et natives est la même : la performance n'est pas un effet de la plateforme, elle est le résultat d'une exécution minutieuse et continue. Le meilleur choix technologique, exécuté sans discipline, donne un produit lent. Un choix modeste, soigneusement exécuté, peut offrir une excellente expérience.

Dans PWA, la discipline se concentre sur le poids et le cache. Dans le natif, dans l’utilisation des ressources et la fluidité. Dans les deux cas, l'ennemi est la complaisance : supposer que c'est rapide parce que c'est rapide pour vous, et découvrir tardivement que ce n'est pas rapide pour l'utilisateur.

Ceux qui construisent pour d’autres personnes doivent mesurer la façon dont ils expérimentent le produit, et non la façon dont il apparaît dans l’environnement de développement contrôlé. Cette humilité, tester sur le pire appareil, sur la pire connexion, est ce qui différencie les produits que les gens utilisent de ceux qu'ils désinstallent.

La décision entre PWA et les questions autochtones. Mais l’exécution compte tout autant, et c’est là que la plupart des produits gagnent ou perdent. La performance est un travail quotidien, et aucune plateforme ne peut remplacer ce travail.