Le déploiement d'un service worker peut modifier les comportements d'un site Web de manière imprévue. Étant donné que Workbox facilite l'écriture et le déploiement d'un service worker, il peut être plus facile de passer à côté de certains effets qu'un service worker a sur un site Web une fois déployé.
Cela ne signifie pas que l'utilisation de Workbox entraîne des résultats insatisfaisants. Toutefois, la commodité qu'elle offre peut faciliter l'écueil de certains pièges si l'utilisateur n'est pas au courant de ce qui se passe lors du déploiement d'un service worker.
Les pièges de la mise en cache préalable
La prémise en cache a été abordée précédemment dans ces documents, mais n'explique pas en détail comment elle peut se contrer. Vous pouvez rencontrer des problèmes si vous appliquez la mise en cache préalable à un trop grand nombre d'éléments ou si le service worker est enregistré avant que la page n'ait eu le temps de charger les éléments critiques.
Étant donné que le comportement par défaut de workbox-webpack-plugin consiste à demander au service worker de pré-mettre automatiquement en cache les éléments générés, cela peut être problématique, d'une manière qui est facile à manquer, car l'obstacle à l'adoption est faible.
workbox-webpack-plugin.
Dans cet exemple, il met en cache 14 éléments dans le projet actuel, pour un total de 352 kilo-octets par défaut.Lorsqu'un service worker effectue un pré-cache des éléments lors de l'installation, une ou plusieurs requêtes réseau sont lancées simultanément. Si ce n'est pas le bon moment, cela peut poser problème à l'utilisateur. Même si le timing est parfait, vous risquez de gaspiller des données si la quantité d'assets mis en pré-cache n'est pas limitée d'une manière ou d'une autre.
Tout est dans le temps
Si un service worker effectue une mise en cache préalable d'un élément, l'heure à laquelle il est enregistré est important.
Les service workers sont souvent enregistrés à l'aide d'éléments <script> intégrés.
Cela signifie que les analyseurs HTML peuvent détecter le code d'enregistrement du service worker avant que les éléments critiques de la page ne soient chargés.
C'est un problème. Idéalement, un service worker doit être neutre en termes de performances dans le pire des cas et ne pas nuire aux performances. Rendez service aux utilisateurs et enregistrez un service worker lorsque l'événement load de la page se déclenche.
Cela réduit le risque que la mise en cache interfère avec le chargement des éléments critiques d'une page, ce qui signifie que la page peut devenir interactive plus rapidement sans avoir à faire face à des requêtes réseau pour des éléments qui ne seront peut-être pas nécessaires avant plus tard.
Réfléchissez bien à votre consommation de données
Quel que soit le délai, la mise en cache préalable consiste à distribuer les requêtes réseau. Si le fichier manifeste des éléments à mettre en cache en amont n'est pas soigneusement sélectionné, il peut y avoir beaucoup de gaspillage.
Le gaspillage de données est un compromis potentiel lié à la mise en cache préalable, mais tout le monde n'a pas accès à une connexion Internet rapide ou même à des forfaits de données illimités. Lors de la mise en cache précoce, envisagez de supprimer les éléments particulièrement volumineux et de vous fier à la mise en cache de l'environnement d'exécution pour les capturer, plutôt que de faire des hypothèses coûteuses.
Le démarrage d'un service worker peut retarder les requêtes réseau
Les service workers s'exécutent dans un processus distinct du reste du code d'un site Web. Ce processus démarre et s'arrête fréquemment. Lorsqu'un service worker doit gérer un événement de récupération après avoir été inactif, le navigateur doit d'abord passer du temps à le démarrer. Cette surcharge supplémentaire avant qu'une requête puisse être traitée est faible par rapport à l'avantage de diffuser une réponse à partir du cache plutôt que du réseau.
Lorsque vous utilisez des stratégies qui ne peuvent pas être diffusées à partir du cache et qui doivent accéder au réseau, en particulier lors du traitement des requêtes de navigation, le temps de démarrage ajoute toujours un certain retard. En fonction des capacités de l'appareil et/ou de la pression du processeur, une requête de navigation peut subir un retard notable en raison de la lenteur du démarrage du service worker. Le déploiement d'un service worker sans être conscient de ce délai peut causer une baisse involontaire des performances pour les utilisateurs.
Ce problème a été résolu avec le préchargement de navigation, mais il n'est pas encore compatible avec tous les navigateurs. Cependant, son utilisation peut valoir la peine d'être envisagée, car nous y reviendrons plus loin dans cette documentation.
Les stratégies axées sur le cache peuvent se déclencher contre
Les stratégies de mise en cache qui consultent d'abord le cache, ou uniquement, sont particulièrement efficaces pour l'accès hors connexion et les performances. Toutefois, elles ont tendance à poser des problèmes dans certains cas.
Mise en cache de l'environnement d'exécution des éléments statiques sans version
Les bundlers créent généralement des éléments statiques avec un hachage basé sur le contenu dans le nom de fichier (par exemple, styles.a4edf38c.css). Dans les service workers qui utilisent des stratégies de mise en cache qui consultent d'abord le cache pour les éléments statiques et qui utilisent une stratégie priorité au réseau pour le balisage de page, il ne devrait pas y avoir de problèmes de mise en cache, car les éléments mis à jour sont référencés dans un balisage qui est toujours extrait du réseau.
Des problèmes surviennent lorsque des éléments statiques sans version sont mis en cache pendant l'exécution à l'aide de ces stratégies.
Si la fonctionnalité d'un site Web est fournie par app.js et qu'une stratégie d'exécution axée sur le cache est utilisée, app.js est mis à jour ultérieurement sans modification du nom de fichier. La version initialement mise en cache continue d'être diffusée à partir du cache au lieu d'être mise à jour.
La solution consiste à utiliser une stratégie qui consulte le réseau pour les mises à jour, par exemple une stratégie de type réseau en priorité ou obsolète pendant la revalidation. Les outils de compilation peuvent également générer un fichier manifeste de mise en cache préalable pour ces éléments, car la logique de mise en cache de Workbox les maintient à jour.
Quoi qu'il en soit, pensez à gérer les versions des éléments statiques, que ce soit par hachage dans le nom de l'élément ou dans la chaîne de requête. Vous éviterez ainsi les problèmes d'éléments obsolètes dans les service workers qui utilisent des stratégies d'exécution axées sur le cache pour les éléments statiques.
Quotas de stockage de l'esprit
Il est courant de déployer des mises à jour de service worker de temps en temps. Lorsque des mises à jour sont déployées, les anciens caches dont les noms ont expiré sont généralement éliminés lors de l'activation du nouveau service worker.
Cependant, certaines itérations de service worker ont une longue durée de vie, ou les noms de cache peuvent ne pas être mis à jour dans les nouvelles mises à jour. Dans ce cas, les anciens éléments statiques peuvent s'accumuler dans des caches à mesure que des mises à jour sont déployées. Les navigateurs définissent des quotas et des limites de stockage. C'est une bonne raison d'être attentif à eux !
Workbox réduit efficacement ces problèmes, mais les quotas de stockage peuvent toujours être dépassés. Vous pouvez contrôler plus précisément les caches avec le module d'expiration de la boîte de travail.
Ne vous inquiétez pas
Le déploiement d'un service worker n'est pas une mince affaire. Pourtant, cela ne devrait pas être un exploit effrayant, malgré un peu de planification et de vigilance sur ce qu'implique le déploiement d'un service worker avec Workbox. Au fur et à mesure que vous continuerez, cette documentation vous aidera à aborder ces préoccupations avec soin et confiance.