Cette documentation aborde la mise en cache précédente, mais pas assez sur la façon de l'utiliser correctement. Cette étape est importante, car que vous utilisiez Workbox ou non, il est facile de mettre en cache une quantité excessive de données et de gaspiller des données et de la bande passante. Vous devez faire attention à l'impact de votre charge utile de mise en cache préalable sur l'expérience utilisateur.
En lisant ce document, vous devez comprendre qu'il s'agit de consignes générales. L'architecture et les exigences de votre application peuvent vous obliger à procéder différemment de celles suggérées ici, mais ces consignes constituent des valeurs par défaut appropriées.
À faire: effectuer une mise en cache préalable des éléments statiques critiques
Les éléments statiques critiques sont les meilleurs candidats à la mise en cache préalable, mais ce qui est considéré comme "critique" élément ? Du point de vue d'un développeur, il peut être tentant de considérer l'ensemble d'une application comme "essentielle", mais du point de vue de l'utilisateur, ce qui compte le plus. Considérez les ressources critiques comme celles qui sont absolument nécessaires pour offrir une expérience utilisateur:
- les feuilles de style globales ;
- Fichiers JavaScript qui fournissent des fonctionnalités globales.
- Code HTML du shell d'application, si cela s'applique à votre architecture.
Rappel: Il ne s'agit que de recommandations générales. Il ne s'agit pas de recommandations strictes. Lors de la mise en cache préalable des éléments, il est préférable de privilégier le moins possible la mise en cache préalable.
À 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 vous appuyer sur une stratégie de mise en cache axée sur le réseau ou uniquement sur le réseau pour gérer les demandes de navigation.
Dans ce cas, vous devez vous assurer que votre service worker met en pré-cache et répond par une page de remplacement hors connexion lorsque l'utilisateur effectue une requête de navigation hors connexion. Pour ce faire, vous pouvez utiliser une stratégie basée sur le réseau uniquement avec un mode hors connexion, en tirant parti du préchargement de la 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 n'est pas dans son cache, il obtient au moins du contenu hors connexion.
Peut-être: envisagez la mise en cache spéculative
C'est un gros "peut-être" mais la mise en cache préalable d'assets qui ne sont utilisés que dans certains cas présente un avantage potentiel. Envisagez les choses de cette façon: les utilisateurs vont devoir télécharger des données en amont, avec l'avantage spéculatif d'accélérer les futures demandes pour ces éléments.
Soyez très prudent si vous décidez de procéder ainsi. Il est facile de gaspiller des données en faisant cela, 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 les éléments qui changent fréquemment, car l'utilisateur subit une utilisation de données supplémentaire chaque fois que le code de pré-mise en cache détecte une nouvelle révision. Observez les parcours utilisateur dans vos données analytiques pour découvrir où les utilisateurs ont tendance à se rendre. Si vous avez des doutes concernant la mise en cache spéculative des assets, il est probablement déconseillé de procéder ainsi.
Nous vous recommandons de ne pas effectuer de mise en cache des éléments HTML statiques avant la mise en cache.
Cette consigne s'applique davantage aux sites statiques dans lesquels des fichiers HTML distincts 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 ou fournis de façon dynamique par un backend d'application. Si cela correspond à votre architecture, il est préférable de ne pas mettre en cache tous les fichiers HTML de votre site Web.
L'un des problèmes liés à la mise en cache préalable des fichiers HTML d'un site entier est que le balisage qui est désormais mis en pré-cache est toujours diffusé à partir du cache plus tard, jusqu'à ce que le service worker soit mis à jour. Cette approche est efficace pour les performances, mais elle peut entraîner une perte importante du cache 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, il est probablement judicieux de mettre en cache toutes ces pages en pré-cache afin qu'elles soient disponibles hors connexion. Si votre site Web est particulièrement volumineux, envisagez de mettre en cache les autres pages de manière spéculative, ainsi que quelques pages à forte valeur ajoutée 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 pré-cache des images responsives ou des favicons
Il ne s'agit pas d'une ligne directrice générale, mais plutôt d'une règle. Les images responsives sont une solution complexe à un problème complexe: de nombreux utilisateurs utilisent de nombreux appareils, dont chacun varie en termes de taille d'écran et de densité de pixels, et la compatibilité avec d'autres formats. Si vous mettez en pré-cache un ensemble entier d'images responsives, vous mettez probablement en cache plusieurs images alors que l'utilisateur risque de n'en télécharger qu'une seule.
Les favcons présentent une situation similaire, dans le sens où les sites Web déploient souvent un ensemble complet de favicons pour différents scénarios. Le plus souvent, un seul favicon est demandé, ce qui engendre un gaspillage tout en mettant en cache un ensemble complet de favicons.
Rendez service à vos utilisateurs et ne prémettez pas en cache les ensembles d'images responsives et de favicons. Utilisez plutôt la mise en cache de l'environnement d'exécution. Si vous devez mettre en cache des images en pré-cache, mettez en cache les images les plus utilisées qui ne font pas partie d'un ensemble d'images responsives ou de favicons. Les fichiers SVG présentent moins de risques en termes de consommation de données. En effet, un seul contenu SVG s'affiche de manière optimale, quelle que soit la densité de pixels d'un écran donné.
À éviter: mettre en pré-cache les polyfills
Faire varier la compatibilité des navigateurs avec les API est un défi permanent pour les développeurs Web, et le polyfill est l'un des moyens de résoudre ce problème. Pour réduire les coûts liés aux performances des polyfills, vous pouvez vérifier les fonctionnalités et ne les charger que pour les navigateurs qui en ont besoin.
Étant donné que le chargement conditionnel des polyfills s'effectue pendant l'exécution par rapport à l'environnement actuel, la mise en cache des polyfills est un pari. Certains utilisateurs en bénéficieront, tandis que d'autres finiront par gaspiller de la bande passante pour des polyfills inutiles.
Ne prémettez pas les polyfills en pré-cache. Comptez sur la mise en cache au moment de l'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 éléments dont vos utilisateurs ont réellement besoin, mais vous pouvez tout à fait procéder correctement en priorisant les performances et la fiabilité futures.
Si vous ne savez pas si certains éléments doivent être mis en pré-cache, il est préférable de demander à Workbox d'exclure ces éléments et de créer un itinéraire de mise en cache pendant l'exécution pour les gérer. Quoi qu'il en soit, la mise en cache préalable est traitée en détail plus loin dans cette documentation. Vous pourrez donc appliquer ces principes à votre logique de mise en cache à l'avenir.