Les services workers peuvent enregistrer des fichiers dans le cache lors de leur installation. C'est ce qu'on appelle le "préchargement". Le précaching permet de diffuser des fichiers mis en cache dans le navigateur sans accéder au réseau. Utilisez le préchargement pour les composants essentiels dont votre site a besoin même en mode hors connexion : page principale, styles, image de remplacement et scripts essentiels.
Pourquoi utiliser Workbox ?
L'utilisation de Workbox pour le préchargement est facultative. Vous pouvez écrire votre propre code pour précharger les éléments critiques lorsque le service worker s'installe. Le principal avantage de l'utilisation de Workbox est son contrôle des versions prêt à l'emploi. La mise à jour des éléments pré-cachés à l'aide de Workbox est beaucoup moins difficile que si vous deviez gérer vous-même le contrôle des versions et la mise à jour de ces fichiers.
Précharger des fichiers manifestes
Le préchargement est basé sur une liste d'URL et d'informations de gestion des versions associées à chaque URL. Ensemble, ces informations sont appelées fichier manifeste de préchargement. Le fichier manifeste est la "source de vérité" pour l'état de tout ce qui doit être dans le préchargement pour une version donnée d'une application Web. Un fichier manifeste de préchargement, 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 composants 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. Pour ce faire, vous devez ajouter un écouteur d'événements fetch dans votre service worker, qui peut vérifier quelles URL ont été pré-mises en cache et renvoyer ces réponses mises en cache de manière fiable, en contournant le réseau. Étant donné que le service worker recherche des réponses dans le cache (et les utilise avant le réseau), on parle de stratégie de cache first.
Mises à jour efficaces
Un fichier manifeste de préchargement fournit une représentation exacte de l'état du cache attendu. 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 mise à jour. Il suffit d'une seule requête réseau, effectuée automatiquement par le navigateur dans le cadre de la vérification de mise à jour du service worker, pour déterminer les URL préchargées à actualiser.
Mises à jour des ressources préchargées
À mesure que vous publiez de nouvelles versions de votre application Web au fil du temps, vous devez mettre à jour les URL préchargées précédemment, précharger de nouveaux composants et supprimer les entrées obsolètes. Tant que vous continuez à générer un fichier manifeste de préchargement complet chaque fois que vous reconstruisez votre site, ce fichier sert de "source de vérité" pour votre état de préchargement à tout moment.
Si une URL existante comporte 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 le cadre des gestionnaires d'événements install et activate. Par exemple, si vous avez apporté des modifications à votre site et reconstruit, votre dernier fichier manifeste de préchargement 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 de 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 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 accède à une page de votre application Web pour la première fois, vous pouvez pré-cacher 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 individuelle.
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é précédemment. Le préchargement offre la même expérience aux applications Web.
Quels éléments devez-vous précharger ?
Reportez-vous au guide Identifier ce qui est chargé pour obtenir une bonne idée des URL à pré-cacher. La règle générale consiste à précacher tout code HTML, JavaScript ou CSS chargé tôt et essentiel à l'affichage de 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.
N'oubliez pas que le précaching implique d'utiliser la bande passante réseau et l'espace de stockage sur l'appareil de l'utilisateur (comme pour installer une application depuis une plate-forme de téléchargement d'applications). En tant que développeur, il vous appartient de procéder à la mise en cache avec précaution 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éguliers de votre application Web bénéficient à long terme du coût initial du préchargement, car la possibilité d'éviter le réseau se paie rapidement en termes de bande passante économisée au fil du temps.