Cette documentation a abordé la mise en cache préalable, mais pas assez sur la façon de l'utiliser correctement. Ce point est important, car que vous utilisiez Workbox ou non, il est facile de procéder à une mise en cache préalable trop importante, ce qui peut entraîner un gaspillage des données et de la bande passante. Vous devez faire attention à l'impact de la charge utile de mise en cache préalable sur l'expérience utilisateur.
En lisant ce document, comprenez qu'il s'agit de directives générales. L'architecture et les exigences de votre application peuvent nécessiter une procédure différente de celle suggérée ici, mais ces directives constituent de bonnes valeurs par défaut.
À faire: effectuer une mise en cache préalable des éléments statiques critiques
Les éléments statiques critiques sont les meilleurs candidats pour la mise en cache préalable, mais qu'est-ce qui est considéré comme un élément "critique" ? Du point de vue du développeur, il peut être tentant de considérer une application entière comme "essentielle", mais le point de vue de l'utilisateur est ce qui compte le plus. Considérez les composants essentiels comme ceux qui sont absolument nécessaires pour offrir une expérience utilisateur:
- Les feuilles de style globales.
- Fichiers JavaScript fournissant des fonctionnalités globales.
- le code HTML du shell d'application, si cela s'applique à votre architecture.
Rappel: Il s'agit de recommandations générales et non de recommandations strictes. Lorsque vous effectuez une mise en cache préalable des éléments, il est préférable de privilégier moins la mise en cache que d'en avoir plusieurs.
À faire: effectuer une mise en cache préalable d'une création de remplacement hors connexion pour les sites Web de plusieurs pages
Pour les sites Web classiques comportant plusieurs pages, vous pouvez avoir recours à une stratégie de mise en cache privilégiant le réseau ou réseau uniquement pour gérer les demandes de navigation.
Dans ce cas, vous devez vous assurer que votre service worker effectue une mise en cache préalable et renvoie une page de remplacement hors connexion lorsque l'utilisateur effectue une requête de navigation hors connexion. Pour ce faire, dans Workbox, vous pouvez par exemple utiliser une stratégie basée uniquement sur le réseau avec un remplacement hors connexion, en tirant également parti du préchargement de navigation:
import {PrecacheFallbackPlugin, precacheAndRoute} from 'workbox-precaching';
import {registerRoute, Route} from 'workbox-routing';
import {NetworkOnly} from 'workbox-strategies';
import * as navigationPreload from 'workbox-navigation-preload';
navigationPreload.enable();
// Ensure that /offline.html is part of your precache manifest!
precacheAndRoute(self.__WB_MANIFEST);
// The network-only callback should match navigation requests, and
// the handler for the route should use the network-only strategy, but
// fall back to a precached offline page in case the user is offline.
const networkOnlyNavigationRoute = new Route(({request}) => {
return request.mode === 'navigate';
}, new NetworkOnly({
plugins: [
new PrecacheFallbackPlugin({
fallbackURL: '/offline.html'
})
]
}));
registerRoute(networkOnlyNavigationRoute);
Ainsi, si un utilisateur se déconnecte et accède à une page qui ne se trouve pas dans son cache, il obtient au moins du contenu hors connexion.
Peut-être faire: envisagez la mise en cache spéculative
C'est peut-être bienvenu, mais il existe un avantage potentiel de mettre en cache des éléments qui ne sont utilisés que dans certains cas. Envisagez les choses de cette façon: les utilisateurs seront soumis à des téléchargements de données supplémentaires en amont, avec l'avantage spéculatif d'accélérer les futures demandes pour ces éléments.
Mise en garde: soyez très prudent si vous décidez de procéder ainsi. Il est facile de gaspiller des données, et cela devrait être une décision basée sur les données. En outre, évitez de mettre en cache de manière spéculative des éléments qui changent fréquemment, car l'utilisateur consomme davantage de données chaque fois que le code de mise en cache détecte une nouvelle révision. Dans vos données analytiques, étudiez les parcours utilisateur. Si vous avez des doutes quant à la mise en cache spéculative des éléments, ne le faites pas.
Évitez de mettre en cache les éléments HTML statiques.
Cette consigne s'applique davantage aux sites statiques où des fichiers HTML discrets sont soit générés par un générateur de site statique, soit créés manuellement, au lieu d'être générés dynamiquement ou fournis par un backend d'application. Si cela décrit votre architecture, il est probablement préférable de ne pas effectuer de pré-cache pour tous les fichiers HTML de votre site Web.
L'un des problèmes liés à la mise en cache préalable de l'intégralité des fichiers HTML d'un site est que le balisage qui est mis en cache à l'instant T sera toujours diffusé depuis le cache jusqu'à ce que le service worker soit mis à jour. Cette approche est très efficace pour les performances, mais peut entraîner une perte de mémoire cache importante si le code HTML de votre site Web change fréquemment.
Il existe toutefois quelques exceptions à cette règle. Si vous déployez un petit site Web avec quelques fichiers HTML statiques, vous pouvez effectuer une mise en cache préalable de toutes ces pages pour qu'elles soient accessibles hors connexion. Si votre site Web est particulièrement volumineux, envisagez de précéder de manière spéculative quelques pages à forte valeur ajoutée et une solution de remplacement hors connexion, et utilisez la mise en cache de l'environnement d'exécution pour mettre en cache les autres pages.
À ne pas faire: mettre en cache à l'avance les images responsives ou les favicons
Il s'agit moins d'une consigne générale, mais plutôt d'une règle. Les images responsives constituent une solution complexe à un problème complexe : de nombreux utilisateurs se servent de nombreux appareils pour répondre à leurs différents types d'appareils : la taille d'écran, la densité de pixels et la compatibilité d'autres formats. Si vous mettez en cache un ensemble entier d'images responsives, il est probable que l'utilisateur mette en cache plusieurs images au lieu d'en télécharger une seule.
La situation des fauves est similaire : les sites Web déploient souvent un ensemble complet de favicons pour différents scénarios. La plupart du temps, un seul favicon est demandé, ce qui réduit le gaspillage de la mise en cache complète d'un ensemble de favicons.
Rendez service à vos utilisateurs : ne mettez pas en cache les images responsives et les favicons. Utilisez plutôt la mise en cache de l'environnement d'exécution. Si vous devez effectuer une mise en cache préalable des images, effectuez une mise en cache préalable des images couramment utilisées qui ne font pas partie d'un ensemble d'images responsives ou de favicons. Les SVG présentent moins de risques en termes de consommation de données : un seul élément SVG s'affiche de manière optimale quelle que soit la densité de pixels d'un écran donné.
À ne pas faire: effectuer une mise en cache préalable des polyfills
La diversité des navigateurs compatibles avec les API représente un défi permanent pour les développeurs Web, et le polyfilling est l'un des moyens permettant de relever ce défi. Pour réduire les coûts de performance des polyfills, vous pouvez vérifier les caractéristiques et ne les charger que pour les navigateurs qui en ont besoin.
Étant donné que le chargement conditionnel des polyfills a lieu pendant l'exécution dans l'environnement actuel, la mise en cache préalable des polyfills n'est pas un jeu d'enfant. Certains utilisateurs en bénéficieront, tandis que d'autres finiront par gaspiller de la bande passante pour des polyfills inutiles.
Ne pas effectuer de mise en cache préalable des polyfills. Appuyez-vous sur la mise en cache de l'environnement d'exécution pour vous assurer qu'elles ne sont mises en cache que dans les navigateurs qui en ont besoin afin d'éviter de gaspiller des données.
Conclusion
La mise en cache préalable nécessite de réfléchir à l'avance aux assets dont vos utilisateurs ont réellement besoin, mais vous pouvez tout à fait le faire tout en priorisant les performances et la fiabilité futures.
Si vous ne savez pas si certains éléments doivent être mis en cache en pré-cache, la meilleure solution consiste peut-être à demander à Workbox de les exclure et de créer un parcours de mise en cache au moment de l'exécution pour les gérer. Dans tous les cas, la mise en cache préalable est expliquée en détail plus loin dans cette documentation. Vous pourrez donc appliquer ces principes à votre logique de mise en cache à l'avenir.