L'une des fonctionnalités des service workers est la possibilité d'enregistrer des fichiers dans le cache lors de l'installation du service worker. C'est ce qu'on appelle la "pré-mise en cache". La mise en cache permet de diffuser des fichiers mis en cache dans le navigateur sans accéder au réseau. Utilisez la mise en cache préalable pour les éléments essentiels dont votre site a besoin, même hors connexion: page principale, styles, image de remplacement et scripts essentiels.
Pourquoi utiliser Workbox ?
L'utilisation de Workbox pour la mise en cache préalable est facultative. Vous pouvez écrire votre propre code pour prémettre en cache les éléments critiques lors de l'installation du service worker. Le principal avantage de Workbox est son contrôle de version prêt à l'emploi. Vous aurez beaucoup moins de difficultés à mettre à jour les éléments en pré-cache à l'aide de Workbox que si vous deviez gérer vous-même la gestion des versions et la mise à jour de ces fichiers.
Fichiers manifestes en pré-cache
La mise en cache préalable s'appuie sur une liste d'URL et sur les informations de gestion des versions associées pour chacune d'elles. Ensemble, ces informations constituent un fichier manifeste de pré-cache. Le fichier manifeste est la "source de référence" de l'état de tout ce qui doit se trouver en pré-cache pour une version donnée d'une application Web. Ce fichier, au format utilisé par Workbox, se présente comme suit:
[{
url: 'app.abcd1234.js'
}, {
url: 'offline.svg',
revision: '7836745f'
}, {
url: 'index.html',
revision: '518747aa'
}]
Lorsque le service worker est installé, trois entrées de cache sont créées dans l'espace de stockage du cache pour chacune des trois URL listées. Le premier élément contient des informations de gestion des versions déjà incluses dans son URL (app correspond au nom réel du fichier et .abcd1234 contient les informations de gestion des versions, juste avant l'extension de fichier .js). Les outils de compilation de Workbox peuvent le détecter et exclure un champ de révision. Les URL des deux autres éléments n'incluent aucune information de gestion des versions. Les outils de compilation de Workbox créent donc un champ revision distinct contenant un hachage du contenu du fichier local.
Diffuser des ressources en pré-cache
L'ajout d'éléments au cache n'est qu'une partie de la pré-mise en cache : une fois les éléments mis en cache, ils doivent répondre aux requêtes sortantes. Cela nécessite un écouteur d'événements fetch dans votre service worker pouvant vérifier quelles URL ont été mises en pré-cache et renvoyer ces réponses mises en cache de manière fiable, en contournant le réseau au cours du processus. Étant donné que le service worker recherche les réponses dans le cache (et les utilise avant le réseau), on parle de stratégie axée sur le cache.
Mises à jour efficaces
Un fichier manifeste en pré-cache fournit une représentation exacte de l'état de cache attendu. Si une combinaison URL/révision change dans le fichier manifeste, un service worker sait que l'entrée mise en cache précédente n'est plus valide et doit être mise à jour. Une seule requête réseau, effectuée automatiquement par le navigateur lors de la vérification des mises à jour du service worker, permet de déterminer les URL en pré-cache à actualiser.
Mises à jour des ressources en pré-cache
À mesure que vous publiez de nouvelles versions de votre application Web, vous devez maintenir à jour les URL précédemment mises en cache, mettre en cache les nouveaux éléments et supprimer les entrées obsolètes. Tant que vous continuez à générer un fichier manifeste complet en pré-cache chaque fois que vous recompilez votre site, ce fichier manifeste sert de "source de référence" pour l'état de mise en cache préalable à tout moment.
S'il existe une URL avec un nouveau champ de révision ou si des URL ont été ajoutées ou supprimées du fichier manifeste, cela indique à votre service worker que des mises à jour doivent être effectuées, dans les gestionnaires d'événements install et activate. Par exemple, si vous avez apporté des modifications à votre site et l'avez recréé, votre dernier fichier manifeste de précache peut avoir subi les modifications suivantes:
[{
url: 'app.ffaa4455.js'
}, {
url: 'offline.svg',
revision: '7836745f'
}, {
url: 'index.html',
revision: '518747aa'
}]
Chacune de ces modifications indique à votre service worker que de nouvelles requêtes doivent être effectuées pour mettre à jour les entrées précédemment mises en cache ('offline.svg' et 'index.html') et mettre en cache les nouvelles URL ('app.ffaa4455.js'), ainsi que des suppressions pour nettoyer les URL qui ne sont plus utilisées ('app.abcd1234.js').
Véritable expérience d'installation sur une plate-forme de téléchargement d'applications
Un autre avantage de la mise en cache préalable est que vous pouvez offrir à vos utilisateurs une expérience qui serait autrement difficile à obtenir en dehors d'une installation sur une "plate-forme de téléchargement d'applications". Lorsqu'un utilisateur visite une page de votre application Web pour la première fois, vous pouvez éventuellement mettre en cache toutes les URL nécessaires pour afficher n'importe quelle vue de votre application Web à l'avance, sans avoir à attendre qu'elles aient consulté chaque affichage.
Lorsqu'un utilisateur installe une application, il s'attend à ce que chaque partie s'affiche rapidement, et pas seulement les vues auxquelles il a accédé par le passé. La mise en cache apporte la même expérience aux applications Web.
Parmi vos éléments, lesquels doivent être mis en pré-cache ?
Consultez le guide Identifier les éléments chargés pour avoir une idée des URL les plus adaptées à la mise en cache préalable. La règle générale consiste à mettre en cache tout élément HTML, JavaScript ou CSS chargé tôt, et qui est essentiel pour afficher la structure de base d'une page donnée.
Il est préférable d'éviter la mise en cache préalable de contenus multimédias ou d'autres éléments chargés ultérieurement (sauf s'ils sont cruciaux pour le fonctionnement de votre application Web). Utilisez plutôt une stratégie de mise en cache de l'environnement d'exécution pour vous assurer que ces éléments sont mis en cache au fur et à mesure.
Gardez toujours à l'esprit que la mise en cache préalable implique l'utilisation de la bande passante réseau et de l'espace de stockage sur l'appareil d'un utilisateur (tout comme l'installation d'une application depuis une plate-forme de téléchargement d'applications). En tant que développeur, c'est à vous qu'il revient de procéder à la mise en cache préalable judicieusement et d'éviter que le fichier manifeste de pré-cache surchargé ne soit surchargé.
Les outils de compilation de Workbox vous aident en vous indiquant le nombre d'éléments dans le fichier manifeste de précache, ainsi que la taille totale de la charge utile de précache.
À long terme, les visiteurs récurrents de votre application Web bénéficient du coût initial de la prémise en cache, car la possibilité d'éviter le réseau s'avère rapidement rentabilisée en économisant la bande passante au fil du temps.