Une progressive web app correspond à un site Web. Tous ses éléments sont identiques à ceux du Web, mais avec de nouveaux outils qui permettent de les charger rapidement en ligne et de les rendre disponibles hors connexion.
Composants de l'application
Le développement d'une application implique généralement plusieurs éléments et ressources, de la logique et du code (compilés ou non) aux éléments de l'interface utilisateur tels que les conceptions d'écran, les images, les logos et les polices.
Une progressive web app est un site Web. Tous ses éléments sont donc les mêmes que sur le Web:
- Code HTML pour le contenu et le rendu initial de la page
- JavaScript pour la logique, y compris la possibilité d'exécuter des modules WebAssembly (code compilé) et d'afficher des graphismes 2D et 3D optimisés par le matériel.
- CSS pour la mise en page, le style et les animations
- Images aux formats Web (PNG, JPEG, WebP et SVG, par exemple)
- Vidéos aux formats Web, tels que MPEG-4 et WebM
- Polices Web
- Données au format JSON ou d'autres formats.
Par défaut, les sites Web téléchargent des éléments sur le réseau, en commençant par le code HTML et en continuant à utiliser les autres ressources.
La gestion de ces ressources pour qu'elles se chargent rapidement et soient disponibles hors connexion représentait un véritable défi pour le Web. Aujourd'hui, les PWA n'utilisent que des fonctionnalités auparavant associées à des applications spécifiques à une plate-forme.
Applications propres à la plate-forme et PWA
Lorsque vous installez une application spécifique à une plate-forme, vous téléchargez généralement un package contenant tous les éléments de l'application: code, images, polices, vidéos, etc. Par conséquent, toutes ces ressources sont disponibles dans l'espace de stockage de votre appareil, même lorsque l'application est hors connexion.
En revanche, un site Web classique a besoin d'une connexion réseau pour télécharger les éléments lorsque cela est nécessaire. Si vous êtes hors connexion, une erreur s'affichera dans le navigateur, car il n'y a pas d'éléments côté client.
L'approche PWA améliore l'expérience Web traditionnelle en rendant tout ou partie des ressources disponibles côté client, comme pour les applications spécifiques à la plate-forme. Par conséquent, lorsque vous ouvrez une PWA, le rendu initial peut être aussi instantané qu'une application de plate-forme, car les assets sont disponibles sans passer par le réseau.
Caches et stockage
Depuis le début du Web, les développeurs n'ont pas le contrôle total sur la mise en cache d'une ressource. Le navigateur est responsable du cache HTTP, et il peut ou non mettre en cache et diffuser des ressources en fonction de différentes règles. D'autres options de stockage, comme le stockage Web et IndexedDB, étaient destinées à enregistrer des données et des objets simples.
Les PWA ne doivent pas se limiter à ces règles pour leur contenu. Aujourd'hui, nous proposons des solutions pour mieux contrôler quand et comment mettre en cache les ressources, et quand et comment les diffuser localement: l'API Cache Storage. Plusieurs solutions de stockage côté client sont disponibles sur le Web:
- Stockage Web:
localStorageetsessionStorageinclus. Ces API stockent des paires de chaînes clé/valeur simples. Le stockage Web est limité et dispose d'une API synchrone. Il est donc préférable de l'éviter autant que possible. - IndexedDB: base de données basée sur des objets (NoSQL) avec une API asynchrone qui offre de bonnes performances Web. IndexedDB peut stocker des données structurées et binaires côté client. C'est généralement ce que vous utiliserez pour stocker des données, comme ce que vous obtenez ou envoyez sous forme de requête API. Il est également utile d'enregistrer les données localement immédiatement, puis de les synchroniser plus tard avec le serveur. L'API IndexedDB permet d'interagir avec la base de données.
- Stockage en cache: ensemble de paires de requêtes et de réponses HTTP permettant de stocker et de récupérer des ressources (avec leurs en-têtes HTTP) exactement telles qu'elles sont transmises par le serveur. L'API Cache Storage vous permet de stocker, de récupérer, de mettre à jour et de supprimer des requêtes réseau, par exemple pour vos éléments, même hors connexion.
Le besoin de service workers
Une PWA peut stocker ses éléments dans l'espace de stockage du cache et dans IndexedDB, mais comment pouvons-nous utiliser ces éléments pour offrir une expérience rapide et hors connexion à vos utilisateurs ? Réponse : Service Workers
Avec un service worker, vous pouvez diffuser des ressources sans passer par le réseau, envoyer des notifications à un utilisateur, ajouter un badge à l'icône de votre PWA, mettre à jour du contenu en arrière-plan et même faire fonctionner l'ensemble de votre PWA hors connexion. Consultez le chapitre suivant pour en savoir plus sur les service workers.
Compatibles hors connexion
Les utilisateurs s'attendent à ce que votre application offre une expérience rapide et toujours prête. Cela signifie que votre application devrait fonctionner hors connexion.
Être disponibles hors connexion ne signifie pas que tous vos contenus ou services doivent être disponibles sans connexion réseau. Toutefois, le fait d'offrir au moins une expérience de base lorsque l'utilisateur est hors connexion, par exemple une page qui vous demande de vous connecter à Internet pour continuer, permettra d'améliorer l'expérience utilisateur, en laissant l'utilisateur dans l'expérience de votre application au lieu d'une erreur de navigateur générique. Dans certains navigateurs, il s'agit d'une fonctionnalité indispensable pour répondre aux critères d'installation des PWA. Il est préférable d'afficher l'interface utilisateur de votre PWA, ainsi que le contenu mis en cache. Permettre aux utilisateurs de continuer à utiliser l'intégralité de votre PWA et synchroniser les modifications du serveur lorsqu'ils sont de nouveau en ligne est la norme absolue pour travailler hors connexion.
Pour rendre votre application disponible hors connexion, vous devez mettre en cache les éléments nécessaires à votre expérience hors connexion et demander à votre service worker de les diffuser ultérieurement. Veillez à ajouter les éléments hors connexion à votre cache avant d'en avoir besoin. Dans certains cas, vous ne pouvez pas les mettre en cache lorsque vous y êtes invité.
Approches fréquemment utilisées pour le cache
Dans votre PWA, vous êtes responsable de toutes les décisions prises. Selon vos besoins, vous pouvez choisir la meilleure approche pour mettre en cache ou installer les éléments. Voici quelques décisions à prendre:
- Prémise en cache: sélectionnez les éléments à installer lors du premier chargement. Ceux-ci doivent inclure le code HTML et le minimum d'éléments permettant d'afficher l'application. Lorsque vous utilisez la mise en cache préalable, n'oubliez pas que vous utilisez l'espace et le réseau de l'appareil. Soyez conscient et responsable lorsque vous téléchargez des éléments et mettez-les en cache.
- Mise en cache selon les besoins: permet d'ajouter des éléments au cache lorsqu'ils sont demandés. En général, il s'agit de composants qui peuvent changer indépendamment de la version de votre application (images ou contenu, par exemple). Consultez la section Mise en cache pour connaître les différentes stratégies de mise en cache selon vos besoins.
- API et services Web: les appels d'API peuvent être mis en cache. Au lieu de mettre en cache les réponses de l'API, vous pouvez stocker leurs données dans IndexedDB.
Mise à jour des éléments...
Dans le modèle d'application standard pour les applications installées via le catalogue d'applications, lorsque les développeurs doivent mettre à jour leur application, ils publient un nouveau package. Les utilisateurs doivent télécharger à nouveau l'intégralité du package, même si la plupart des éléments n'ont pas changé. Avec les PWA, en suivant les approches décrites dans la section ci-dessus, vous décidez quand et comment mettre à jour les éléments. Voici différentes options pour mettre à jour des éléments:
- Mise à jour complète: dans ce cas, chaque fois que vous apportez une modification à l'application, même mineure, votre code télécharge à nouveau tous les éléments dans le cache.
- Mise à jour partielle: dans cette approche, vous créez une méthode pour définir quels éléments ont été mis à jour et vous ne mettez à jour que ceux-ci, avec ou sans l'intervention de l'utilisateur.
- Mise à jour continue: grâce à cette technique, vos assets sont vérifiés et mis à jour automatiquement chaque fois qu'une PWA est utilisée.
Taille et durée de vie
Généralement, les applications spécifiques à une plate-forme ne sont pas soumises à des limites de taille. Lors de l'installation, la taille des applications peut atteindre plusieurs gigaoctets. Tant que l'appareil a la capacité suffisante, l'installation sera autorisée. De plus, une fois installée, l'application utilise cet espace de stockage total, que vous l'utilisiez ou non. Le stockage est géré différemment pour les PWA. Le navigateur stocke vos éléments en fonction des règles que vous définissez dans la logique de votre PWA.
Les limites de taille dépendent du navigateur. Il n'est pas aussi flexible que les applications spécifiques à une plate-forme, mais il convient généralement à la plupart des applications Web. Pour connaître les limites spécifiques à chaque navigateur, consultez cet article.
Si l'utilisateur se sert de votre PWA dans son navigateur, les navigateurs peuvent expulser des éléments en fonction de la saturation de l'espace de stockage, ou après quelques semaines d'inactivité. Sur certaines plates-formes, si l'utilisateur installe votre PWA, aucune éviction ne se produira. Le cas échéant, le code peut demander un stockage persistant via une API pour éviter cette éviction.