Quelles sont les caractéristiques d'une progressive web app de qualité ?

Les performances jouent un rôle important dans le succès de toute expérience en ligne, car les sites très performants enregistrent un meilleur engagement et une meilleure fidélisation des utilisateurs que les sites moins performants. Concentrez-vous sur l'optimisation des métriques de performances centrées sur l'utilisateur.

Pourquoi

La vitesse est essentielle pour inciter les utilisateurs à utiliser votre application. En effet, si le temps de chargement de la page passe d'une à dix secondes, la probabilité qu'un utilisateur quitte votre application augmente de 123%. Les performances ne s'arrêtent pas non plus avec l'événement load. Les utilisateurs ne doivent jamais se demander si leur interaction (par exemple, un clic sur un bouton) a été enregistrée ou non. Le défilement et l'animation doivent être fluides. Les performances affectent l'ensemble de votre expérience, à la fois dans le comportement de votre application et dans la façon dont les utilisateurs la perçoivent.

Bien que toutes les applications aient des besoins différents, les audits de performances de Lighthouse sont basés sur les Core Web Vitals. Si vous obtenez un score élevé lors de ces audits, vos utilisateurs auront plus de chances de profiter d'une expérience agréable. Vous pouvez également utiliser PageSpeed Insights ou le rapport d'expérience utilisateur Chrome pour obtenir des données de performances réelles pour votre application Web.

Comment

Suivez notre guide sur les temps de chargement rapides pour découvrir comment faire démarrer et rester rapide votre PWA.

Les utilisateurs peuvent utiliser n'importe quel navigateur de leur choix pour accéder à votre application Web avant qu'elle ne soit installée.

Pourquoi

Les progressive web apps sont d'abord des applications Web. Par conséquent, elles doivent fonctionner dans tous les navigateurs.

Selon Jeremy Keith dans Resilient Web Design, un moyen efficace d'y parvenir consiste à identifier les principales fonctionnalités, à les rendre disponibles à l'aide de la technologie la plus simple possible, puis à améliorer l'expérience dans la mesure du possible. Dans de nombreux cas, cela signifie commencer par le code HTML uniquement pour créer les fonctionnalités de base, puis améliorer l'expérience utilisateur avec le code CSS et JavaScript pour créer une expérience plus attrayante.

Prenons l'envoi d'un formulaire comme exemple. Le moyen le plus simple d'implémenter cela est un formulaire HTML qui envoie une requête POST. Une fois cette étape terminée, vous pouvez améliorer l'expérience avec JavaScript pour effectuer la validation du formulaire et l'envoyer via AJAX, ce qui améliore l'expérience pour les utilisateurs qui peuvent l'utiliser.

Vos utilisateurs accèdent à votre site sur un large éventail d'appareils et de navigateurs. Vous ne pouvez pas simplement cibler l'extrémité supérieure de ce spectre. Utilisez la détection de fonctionnalités pour offrir une expérience utilisable au plus grand nombre d'utilisateurs potentiels possible, y compris ceux qui utilisent des navigateurs et des appareils qui n'existent pas encore.

Comment

Resilient Web Design de Jeremy Keith est une excellente ressource qui décrit comment penser la conception Web dans cette méthodologie progressive multinavigateur.

Autres ressources

• L'article Understanding Progressive Enhancement (Comprendre l'amélioration progressive) d'A List Apart est un bon point de départ pour ce sujet.
• Article de Smashing Magazine sur la amélioration progressive fournit une introduction pratique et des liens vers des sujets plus avancés.
• L'article Implémenter la détection de fonctionnalités de MDN explique comment détecter une fonctionnalité en la interrogeant directement.

Les utilisateurs peuvent utiliser votre PWA sur n'importe quelle taille d'écran, et l'ensemble de son contenu est disponible à n'importe quelle taille de fenêtre.

Pourquoi

Les appareils sont de différentes tailles, et les utilisateurs peuvent utiliser votre application à différentes tailles, même sur le même appareil. Il est donc essentiel de vous assurer non seulement que votre contenu s'affiche dans la fenêtre d'affichage, mais aussi que toutes les fonctionnalités et tous les contenus de votre site sont utilisables à toutes les tailles de fenêtre d'affichage.

Les tâches que les utilisateurs souhaitent accomplir et les contenus auxquels ils souhaitent accéder ne changent pas avec la taille de la fenêtre d'affichage. Vous pouvez réorganiser votre contenu pour différentes tailles de fenêtre d'affichage. Il devrait être visible, d'une manière ou d'une autre. En fait, comme Luke Wroblewski le déclare dans son livre Mobile First, commencer par un petit écran et ajuster votre conception pour les écrans plus grands peut améliorer la conception d'un site:

Les appareils mobiles exigent que les équipes de développement logiciel se concentrent uniquement sur les données et les actions les plus importantes d'une application. Un écran de 320 x 480 pixels n'a tout simplement pas la place pour des éléments superflus. Vous devez établir des priorités.

Comment

De nombreuses ressources sont disponibles sur le responsive design, y compris l'article original d'Ethan Marcotte, une collection de concepts importants associés, ainsi que de nombreux livres et conférences. Pour affiner cette discussion sur les aspects de contenu du responsive design, consultez la conception axée sur le contenu et les mises en page responsives axées sur le contenu. Enfin, bien que l'article Seven Deadly Mobile Myths (Sept mythes mortels sur les mobiles) de Josh Clark soit axé sur les mobiles, les leçons qu'il contient sont tout aussi pertinentes pour les vues de petite taille des sites responsifs que pour les mobiles en général.

Lorsque les utilisateurs sont hors connexion, les laisser dans votre PWA offre une expérience plus fluide que de revenir à la page hors connexion du navigateur par défaut.

Pourquoi

Les utilisateurs s'attendent à ce que les applications installées fonctionnent, quel que soit leur état de connexion. Une application spécifique à une plate-forme n'affiche jamais de page vierge lorsqu'elle est hors connexion, et une PWA ne doit jamais afficher la page hors connexion par défaut du navigateur. Fournir une expérience hors connexion personnalisée, à la fois lorsqu'un utilisateur accède à une URL qui n'a pas été mise en cache et lorsqu'il tente d'utiliser une fonctionnalité nécessitant une connexion, permet de donner l'impression que votre expérience Web fait partie de l'appareil sur lequel elle s'exécute.

Comment

Lors de l'événement install d'un service worker, vous pouvez pré-cacher une page hors connexion personnalisée à afficher lorsqu'un utilisateur passe en mode hors connexion. Consultez la section Créer une page de remplacement hors connexion pour savoir comment l'implémenter vous-même. Notez que Chrome affichera une page hors connexion de base si aucune n'est fournie.

Les utilisateurs qui installent ou ajoutent des applications à leur appareil ont tendance à interagir davantage avec ces applications.

Pourquoi

L'installation d'une progressive web app lui permet de ressembler à toutes les autres applications installées et de se comporter comme elles. Elle est lancée à partir du même endroit que les autres applications. Elle s'exécute dans sa propre fenêtre d'application, distincte du navigateur, et apparaît dans la liste des tâches, comme les autres applications.

Comme pour les applications spécifiques à un appareil, les utilisateurs qui installent vos applications constituent votre audience la plus engagée. Ils présentent souvent des métriques d'engagement équivalentes à celles des utilisateurs d'applications sur les appareils mobiles. Ces métriques incluent un plus grand nombre de visites répétées, une durée de visite plus longue sur votre site et des taux de conversion plus élevés que ceux des visiteurs habituels.

Comment

Suivez notre guide sur les applications installables pour découvrir comment rendre votre PWA installable.

Lorsque la connectivité n'est pas strictement requise, votre application fonctionne de la même manière hors connexion qu'en ligne.

Pourquoi

En plus de fournir une page hors connexion personnalisée, les utilisateurs s'attendent à ce que les PWA soient utilisables hors connexion. Par exemple, les applications de voyage et de compagnie aérienne doivent proposer les informations sur le voyage et les cartes d'embarquement facilement accessibles lorsque vous êtes hors connexion. Les applications de musique, de vidéo et de podcasting doivent permettre la lecture hors connexion. Les applications de réseaux sociaux et d'actualités doivent mettre en cache les contenus récents afin que les utilisateurs puissent les lire hors connexion. Les utilisateurs s'attendent également à rester authentifiés lorsqu'ils sont hors connexion. Concevez donc votre application pour l'authentification hors connexion. Une PWA hors connexion offre une véritable expérience semblable à celle d'une application aux utilisateurs.

Comment

Après avoir déterminé les fonctionnalités que vos utilisateurs s'attendent à utiliser hors connexion, vous devez rendre vos contenus disponibles et adaptables aux contextes hors connexion. Vous pouvez utiliser IndexedDB, un système de stockage NoSQL dans le navigateur, pour stocker et récupérer des données, et la synchronisation en arrière-plan pour permettre aux utilisateurs d'effectuer des actions hors connexion et de différer les communications avec le serveur jusqu'à ce que l'utilisateur dispose de nouveau d'une connexion stable. Vous pouvez également utiliser des workers de service pour stocker d'autres types de contenus, tels que des images, des fichiers vidéo et des fichiers audio, pour une utilisation hors connexion, et pour implémenter des sessions sécurisées et durables afin de maintenir l'authentification des utilisateurs. Du point de vue de l'expérience utilisateur, vous pouvez utiliser des écrans squelettes qui donnent aux utilisateurs une perception de la vitesse et du contenu pendant le chargement, qui peut ensuite revenir au contenu mis en cache ou à un indicateur hors connexion si nécessaire.

Toutes les interactions utilisateur respectent les exigences d'accessibilité WCAG 2.0.

Pourquoi

À un moment donné, la plupart des utilisateurs souhaitent utiliser votre PWA d'une manière conforme aux exigences d'accessibilité WCAG 2.0. La capacité des utilisateurs à interagir avec votre PWA et à la comprendre varie, et les besoins peuvent être temporaires ou permanents. En rendant votre PWA accessible, vous la rendez utilisable par tous.

Comment

La Introduction à l'accessibilité Web du W3C constitue un bon point de départ. La majorité des tests d'accessibilité doivent être effectués manuellement. Des outils tels que les audits accessibilité dans Lighthouse, axe et Insights sur l'accessibilité peuvent vous aider à automatiser certains tests d'accessibilité. Il est également important d'utiliser des éléments sémantiquement corrects au lieu de les recréer vous-même, par exemple les éléments a et button. Cela garantit que lorsque vous devez créer des fonctionnalités plus avancées, les attentes en matière d'accessibilité sont satisfaites (par exemple, quand utiliser des flèches plutôt que des onglets). A11Y Nutrition Cards fournit d'excellents conseils à ce sujet pour certains composants courants.

Votre PWA peut être facilement découvert dans la recherche.

Pourquoi

L'un des plus grands avantages du Web est la possibilité de découvrir des sites et des applications via la recherche. En réalité, plus de la moitié du trafic vers un site Web provient de la recherche naturelle. Il est essentiel de s'assurer que des URL canoniques existent pour le contenu et que les moteurs de recherche peuvent indexer votre site afin que les utilisateurs potentiels puissent trouver votre PWA. C'est particulièrement vrai lors de l'adoption du rendu côté client.

Comment

Commencez par vous assurer que chaque URL comporte un titre et une meta description uniques et descriptifs. Vous pouvez ensuite utiliser la Google Search Console et les audits d'optimisation pour les moteurs de recherche dans Lighthouse pour déboguer et résoudre les problèmes de visibilité de votre PWA. Vous pouvez également utiliser les outils pour les propriétaires de sites de Bing ou de Yandex, et envisager d'inclure des données structurées à l'aide de schémas de Schema.org dans votre PWA.

Votre PWA est utilisable aussi bien avec une souris, un clavier, un stylet ou un écran tactile.

Pourquoi

Les appareils proposent différentes méthodes d'entrée, et les utilisateurs doivent pouvoir passer facilement de l'une à l'autre lorsqu'ils utilisent votre application. Tout aussi important, les méthodes d'entrée ne doivent pas dépendre de la taille de l'écran. Autrement dit, les grands viewports doivent être compatibles avec le tactile, et les petits viewports doivent être compatibles avec les claviers et les souris. Dans la mesure du possible, assurez-vous que votre application et toutes ses fonctionnalités sont compatibles avec toutes les méthodes de saisie que votre utilisateur peut choisir. Le cas échéant, améliorez les expériences pour permettre également des commandes spécifiques aux entrées (comme le balayage pour actualiser).

Comment

L'API Pointer Events fournit une interface unifiée pour travailler avec différentes options d'entrée. Elle est particulièrement adaptée à l'ajout de la compatibilité avec le stylet. Pour prendre en charge à la fois l'écran tactile et le clavier, assurez-vous d'utiliser les éléments sémantiques appropriés (ancres, boutons, commandes de formulaire, etc.) et de ne pas les reconstruire avec du code HTML non sémantique. Lorsque vous incluez des interactions qui s'activent lorsque vous pointez dessus, assurez-vous qu'elles peuvent également s'activer en cliquant ou en appuyant dessus.

Lorsque vous demandez l'autorisation d'utiliser des API puissantes, fournissez un contexte et ne demandez l'autorisation que lorsque l'API est nécessaire.

Pourquoi

Les API qui déclenchent une invite d'autorisation, comme les notifications, la géolocalisation et les identifiants, sont conçues intentionnellement pour perturber l'utilisateur, car elles ont tendance à être liées à des fonctionnalités puissantes qui nécessitent une activation. Le déclenchement de ces requêtes sans contexte supplémentaire, comme lors du chargement de la page, rend les utilisateurs moins susceptibles d'accepter ces autorisations et plus susceptibles de ne pas leur faire confiance à l'avenir. À la place, ne déclenchez ces invites qu'après avoir expliqué à l'utilisateur pourquoi vous avez besoin de cette autorisation dans le contexte.

Comment

L'article UX des autorisations et l'article Les bonnes façons de demander des autorisations aux utilisateurs d'UX Planet sont de bonnes ressources pour comprendre comment concevoir des requêtes d'autorisation qui, bien que centrées sur le mobile, s'appliquent à tous les PWA.

En gardant votre codebase en bon état, vous pouvez plus facilement atteindre vos objectifs et proposer de nouvelles fonctionnalités.

Pourquoi

La création d'une application Web moderne nécessite de nombreux éléments. En gardant votre application à jour et votre codebase en bon état, vous pouvez plus facilement proposer de nouvelles fonctionnalités qui répondent aux autres objectifs définis dans cette checklist.

Comment

Plusieurs vérifications de priorité élevée permettent de s'assurer que le codebase est sain:

• Évitez d'utiliser des bibliothèques présentant des failles connues.
• Assurez-vous de ne pas utiliser d'API obsolètes.
• Supprimez les pratiques de codage dangereuses de votre codebase (par exemple, en utilisant document.write() ou en disposant d'écouteurs d'événements de défilement non passifs).
• Vous pouvez même coder de manière défensive pour vous assurer que votre PWA ne plante pas si les données analytiques ou d'autres bibliothèques tierces ne se chargent pas.
• Envisagez d'exiger une analyse de code statique, comme l'analyse lint, ainsi que des tests automatisés dans plusieurs navigateurs et canaux de publication. Ces techniques peuvent aider à détecter les erreurs avant qu'elles ne soient mises en production.