Les service workers permettent d'enregistrer des fichiers dans le cache que le service worker est en cours d'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 sur le réseau. Utilisez la mise en cache préalable pour les composants essentiels dont votre site a besoin, 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 prémettre en cache les éléments critiques lors de l'installation par le service worker. Le principal avantage de Workbox est son contrôle des versions prêt à l'emploi. La mise à jour des éléments en pré-cache avec Workbox sera beaucoup moins difficile 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 version associées associées pour chaque URL. Ensemble, ces informations sont connues sous le nom de fichier manifeste de mise en cache préalable. Le manifeste est la "source de vérité" pour l'état de tout ce qui devait se trouver dans la pré-cache d'une version donnée d'une application Web. Un fichier manifeste de mise en cache préalable, dans la utilisé par Workbox, ressemble à ceci:
[{
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
Espace de stockage du cache, pour chacune des trois URL répertoriées. La gestion des versions est appliquée au premier élément
informations déjà incluses dans l'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. La
les deux autres éléments n'incluent pas d'informations de gestion des versions dans leurs URL. Par conséquent,
de compilation créent un champ revision distinct, contenant un hachage de l'adresse
le contenu du fichier.
Diffuser des ressources mises en cache
L'ajout d'éléments au cache n'est qu'une partie du processus de mise en cache préalable : une fois que le
sont mis en cache, ils doivent répondre
aux requêtes sortantes. Cela nécessite
Écouteur d'événements fetch dans votre service worker qui peut vérifier les URL présentant
ont été mises en pré-cache et renvoient ces réponses en cache de manière fiable, en contournant
réseau dans ce processus. Comme le service worker recherche des réponses dans le cache
(et qui les utilise avant le réseau), c'est ce qu'on appelle
stratégie axée sur le cache axée sur le cache.
Mises à jour efficaces
Un fichier manifeste de pré-cache fournit une représentation exacte du cache attendu state; si une combinaison URL/révision du fichier manifeste change, un service worker sait que l'entrée mise en cache précédente n'est plus valide et doit être mis à jour. Il suffit d'une seule requête réseau, effectuée automatiquement par dans le cadre du service worker vérification des mises à jour, pour 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, à jour les URL mises en pré-cache, mettre en cache les nouveaux éléments et supprimer les URL obsolètes les entrées correspondantes. Tant que vous continuez à générer un fichier manifeste de mise en cache complet à chaque fois lorsque vous reconstruisez votre site, ce fichier manifeste sert de "source de vérité" pour votre l'état de pré-cache à tout moment.
S'il existe une URL avec un nouveau champ de révision ou si des URL ont été
ajouté ou supprimé du fichier manifeste, c'est un signe pour votre service worker qui
doivent être effectuées, dans le cadre
install
et
activate
et les gestionnaires d'événements. Par exemple, si vous avez apporté des modifications à votre site
le dernier fichier manifeste de précache a peut-être été soumis aux
modifications:
[{
url: 'app.ffaa4455.js'
}, {
url: 'offline.svg',
revision: '7836745f'
}, {
url: 'index.html',
revision: '518747aa'
}]
Chacune de ces modifications indique à votre service worker que les nouvelles requêtes doivent être
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').
Vraie "plate-forme de téléchargement d'applications" expérience d'installation
Un autre avantage de la mise en cache préalable est que vous pouvez offrir à vos utilisateurs une expérience serait difficile à réaliser en dehors d'une "plate-forme de téléchargement d'applications" l'installation. 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 l'une de vos les vues de votre application Web à l'avance, sans avoir à attendre qu'ils y accèdent une vue individuelle.
Lorsqu'un utilisateur installe une application, il s'attend à ce que chaque partie s'affiche rapidement, pas seulement sur les vues qu'ils ont connues dans le passé. La mise en cache préalable apporte la même aux applications Web.
Quels éléments doivent être mis en pré-cache ?
Reportez-vous à la section Identifier pour obtenir un bon résultat des URL les plus logiques à mettre en cache. La règle générale est de mettre en cache tout code HTML, JavaScript ou CSS chargé dès le début et essentiel pour affichant la structure de base d'une page donnée.
Il est préférable d'éviter la mise en cache préalable des médias ou d'autres éléments chargés ultérieurement. (sauf si elle est essentielle pour le fonctionnement de votre application Web). Utilisez plutôt un environnement d'exécution de mise en cache pour vous assurer 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 depuis une plate-forme de téléchargement d'applications). En tant que développeur, c'est à vous, en tant que développeur, de procéder à la mise en cache avec précaution et d'éviter une surcharge le fichier manifeste de mise en cache préalable.
Les outils de compilation de Workbox vous aident en indiquant le nombre d'éléments mis en pré-cache le fichier manifeste 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 pré-mise en cache, car la capacité qu'elle offre à éviter le réseau paie rapidement de la bande passante économisée au fil du temps.