Les service workers offrent la possibilité d'enregistrer des fichiers dans le cache lors de leur installation. C'est ce que l'on appelle la "mise en cache préalable". La mise en cache préalable 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 critiques 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 des versions prêt à l'emploi. Vous rencontrerez beaucoup moins de problèmes pour mettre à jour des é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.
Mettre en pré-cache les fichiers manifestes
La mise en cache préalable est régie par une liste d'URL et les informations de gestion des versions associées pour chaque URL. Ensemble, ces informations constituent un fichier manifeste de pré-cache. Le fichier manifeste est la "source de référence" pour l'état de tout ce qui est censé se trouver dans le précache pour une version donnée d'une application Web. Un fichier manifeste de précache, 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 le stockage du cache, pour chacune des trois URL répertoriées. L'URL du premier élément contient des informations de gestion des versions déjà incluses dans son URL (app est le nom de fichier réel, tandis que .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 deux autres éléments n'incluent aucune information de gestion des versions dans leurs URL. Par conséquent, les outils de compilation de Workbox créent un champ revision distinct, contenant un hachage du contenu du fichier local.
Diffuser des ressources mises en cache
L'ajout d'éléments au cache ne représente qu'une partie du processus de mise en cache préalable : 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, capable de vérifier quelles URL ont été mises en pré-cache et de renvoyer ces réponses mises en cache de manière fiable, contournant ainsi le réseau. Étant donné que le service worker vérifie les réponses dans le cache (et les utilise avant le réseau), cela s'appelle une stratégie orientée cache.
Mises à jour efficaces
Un fichier manifeste de pré-cache fournit une représentation exacte de l'état de cache attendu. Si une combinaison URL/révision dans le fichier manifeste change, 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 mises 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 de précache complet chaque fois que vous recréez votre site, ce fichier manifeste sert de "source d'informations" pour votre état de précache à tout moment.
S'il existe une URL existante 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 que vous l'avez recréé, le dernier fichier manifeste de précache a peut-être 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 les suppressions pour nettoyer les URL qui ne sont plus utilisées ('app.abcd1234.js').
Véritable expérience d'installation depuis 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 de l'installation d'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 potentiellement mettre en pré-cache toutes les URL nécessaires pour afficher n'importe quelle vue de votre application Web à l'avance, sans avoir à attendre qu'il accède à chaque vue.
Lorsqu'un utilisateur installe une application, il s'attend à ce que toutes ses parties s'affichent rapidement, et pas seulement les vues qu'il a consultées par le passé. La mise en cache préalable offre la même expérience aux applications Web.
Quels éléments doivent être mis en pré-cache ?
Reportez-vous au guide Identifier les éléments chargés pour obtenir un bon aperçu des URL les plus pertinentes pour le pré-cache. La règle générale consiste à mettre en pré-cache tout code HTML, JavaScript ou CSS chargé dès le début. Cet élément 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 des contenus multimédias ou d'autres éléments chargés ultérieurement (sauf s'ils sont essentiels au fonctionnement de votre application Web). Utilisez plutôt une stratégie de mise en cache pendant l'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 et du stockage réseau sur l'appareil d'un utilisateur (tout comme l'installation d'une application à partir d'une plate-forme de téléchargement d'applications). En tant que développeur, il vous appartient de procéder à la mise en cache de manière appropriée et d'éviter un fichier manifeste de précache 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.
Les visiteurs récurrents de votre application Web bénéficient à long terme du coût initial de la mise en cache, car la possibilité qu'elle permet d'éviter le réseau s'avère rapidement rentable en bande passante économisée au fil du temps.