Les utilisateurs qui chargent votre site une deuxième fois utiliseront leur cache HTTP. cela fonctionne bien.
Ce post accompagne la vidéo Love your cache, qui fait partie de la série Contenu du Chrome Dev Summit 2020 N'oubliez pas de regarder la vidéo:
Lorsque les utilisateurs chargent votre site une deuxième fois, leur navigateur utilise les ressources qu'ils contiennent son cache HTTP pour accélérer le chargement. Mais les normes de mise en cache sur Internet remontent à 1999. Leur définition est assez large, déterminant si un fichier, comme un fichier CSS ou une image, peut être récupéré à nouveau sur le réseau par rapport au chargement chargé à partir de votre cache n'est pas une science exacte.
Dans cet article, je vais vous présenter une solution par défaut adaptée et moderne pour la mise en cache, n'effectue aucune mise en cache. Mais ce n'est que la valeur par défaut, bien plus nuancé qu'une simple "désactivation". Lisez la suite.
Objectifs
Lorsqu'un site se charge pour la deuxième fois, vous avez deux objectifs:
- Veillez à ce que vos utilisateurs disposent de la version la plus récente, si vous avez effectué des changements, les changements devraient se répercuter rapidement
- Effectuez la première opération en récupérant le moins possible d'informations sur le réseau.
Au sens le plus large, vous voulez n'envoyer que la plus petite modification à vos clients lorsqu'ils chargent à nouveau votre site. Et si vous structurez votre site pour vous assurer il est difficile de répartir les changements de façon efficace (plus d'informations à ce sujet ci-dessous, la vidéo).
Cela dit, vous disposez d'autres commandes pour la mise en cache, comme vous avez décidé de laisser le cache HTTP du navigateur d'un utilisateur conserver votre site pendant longtemps afin qu'aucune requête réseau ne soit nécessaire pour la diffuser. Ou vous avez a construit un service worker qui desservira un site entièrement hors ligne avant que pour vérifier s'il est à jour. Il s'agit d'une option extrême valide, pour de nombreuses expériences Web de type application hors connexion, mais le Web n'a pas besoin d'être à un niveau extrême du cache uniquement, ou même complètement au réseau.
Contexte
En tant que développeurs Web, nous sommes tous habitués à l'idée de disposer d'un "cache non actualisé". Mais nous savons, presque instinctivement, les outils à notre disposition pour résoudre ce problème: faire une Actualiser", ouvrir une fenêtre de navigation privée, ou utiliser à la fois les pour effacer les données d'un site.
Les internautes ordinaires n'ont pas le même luxe. Alors que nous ont pour principal objectif de veiller à ce que les utilisateurs passent un bon moment avec leur deuxième il est également très important de s'assurer qu'ils ne subissent pas de mauvais moment ou être bloqué. (Regardez la vidéo pour m'expliquer avez failli bloquer le site web.dev/live.)
Pour information, le cache est souvent "obsolète". est en fait
la valeur par défaut de 1999
pour la mise en cache. Il repose sur l'en-tête Last-Modified:
Chaque fichier que vous chargez est conservé pendant 10% de sa durée de vie actuelle, car
votre navigateur le détecte. Par exemple, si index.html a été créé il y a un mois,
il est mis en cache par votre navigateur
pendant environ trois jours supplémentaires.
C'était une idée bien intentionnée à l'époque, mais compte tenu de la intégré aux sites Web d'aujourd'hui. Ce comportement par défaut permet qu'un utilisateur dispose de fichiers conçus pour différentes versions votre site Web (le code JavaScript de la version de mardi et le CSS de vendredi car ces fichiers n'ont pas été mis à jour exactement en même temps.
Un chemin bien éclairé
Par défaut, la mise en cache n'effectue pas de mise en cache du tout et utilise CDN pour rapprocher votre contenu à vos utilisateurs. Chaque fois qu'un utilisateur charge votre site, il accède au réseau voir s’il est à jour. Cette requête aura une faible latence, fournies par un CDN géographiquement proche de chaque utilisateur final.
Vous pouvez configurer votre hébergeur Web pour qu'il réponde aux requêtes Web avec cet en-tête:
Cache-Control: max-age=0,must-revalidate,public
Cela dit en gros : le fichier n'est valide pour aucun moment, et vous devez valider du réseau avant de pouvoir l'utiliser à nouveau (sinon, ce n'est "suggéré").
Ce processus de validation est relativement peu coûteux en termes d'octets transférés. Si un n'a pas été modifié, votre navigateur recevra un code 304 de petite taille mais cela entraîne un coût de latence, car l'utilisateur doit tout de même accéder au réseau pour trouver s'affiche. C'est le principal inconvénient de cette approche. Cela peut très bien fonctionner pour ceux qui disposent d'une connexion rapide dans le premier monde et où le CDN de votre choix une excellente couverture, mais pas pour les personnes qui utilisent un mobile plus lent des connexions ou en utilisant une mauvaise infrastructure.
Quoi qu'il en soit, il s'agit d'une approche moderne qui est l'option par défaut sur un CDN populaire, Netlify, mais il peut être configuré sur presque n'importe quel CDN. Pour Firebase Hosting, vous pouvez inclure cet en-tête dans la section "Hébergement" de votre fichier firebase.json:
"headers": [
// Be sure to put this last, to not override other headers
{
"source": "**",
"headers": [ {
"key": "Cache-Control",
"value": "max-age=0,must-revalidate,public"
}
}
]
Par conséquent, même si je suggère toujours cette option comme valeur par défaut, il n'y a que cela, la valeur par défaut. Poursuivez votre lecture pour découvrir comment modifier les valeurs par défaut.
URL avec empreinte
En incluant un hachage du contenu du fichier dans le nom des éléments, des images, etc.
sur votre site, vous pouvez faire en sorte que ces fichiers soient toujours associés à
du contenu (vous obtiendrez par exemple des fichiers nommés sitecode.af12de.js). Quand ?
votre serveur répond aux requêtes pour ces fichiers, vous pouvez demander à votre
aux navigateurs de l'utilisateur final de les mettre en cache pendant une longue période en les configurant
en-tête:
Cache-Control: max-age=31536000,immutable
Cette valeur est une année, en secondes. Selon les spécifications, égal à "définitivement".
Il est important de noter que ne générez pas ces hachages à la main : cela représente trop de travail manuel ! Toi des outils comme Webpack, Rollup, etc. peuvent vous y aider. Assurez-vous que . Pour en savoir plus, consultez le rapport sur les outils.
N'oubliez pas que le code JavaScript n'est pas le seul à utiliser les URL avec empreintes digitales. des éléments tels que des icônes, des CSS et d'autres fichiers de données immuables peuvent également être nommés de cette façon. de la même façon. N'oubliez pas de regarder la vidéo ci-dessus pour en savoir plus sur le code qui vous permet d'envoyer moins de code en cas de modification de votre site.)
Quelle que soit l'approche adoptée par votre site pour la mise en cache, ces types de fingerprinting fichiers sont incroyablement précieux pour tout site que vous pourriez créer. La plupart des sites ne font que ne changent pas à chaque version.
Bien entendu, nous ne pouvons pas renommer nos pages "conviviales", destinées aux utilisateurs, de cette façon :
votre fichier index.html vers index.abcd12.html : ce qui est impossible, vous ne pouvez pas
d'accéder à une nouvelle URL à chaque fois qu'ils chargent votre site ! Ces "amicales" URL
ne peuvent pas être renommées et mises en cache de cette façon, ce qui m'amène à un point intermédiaire
sur le terrain.
Au milieu
Il y a évidemment de la place pour un terrain d’entente pour la mise en cache. J'ai présenté deux options extrêmes : mettre en cache never ou toujours. Et il y aura un certain nombre de fichiers que vous voudrez peut-être mettre en cache pendant un certain temps, comme "amical" les URL mentionnées ci-dessus.
Si vous souhaitez les mettre en cache, les URL et leur code HTML, il vaut mieux tenez compte des dépendances qu'elles incluent, de la manière dont elles peuvent être mises en cache et mettre en cache leurs URL pendant un certain temps peut vous affecter. Examinons une page HTML qui inclut une image comme celle-ci:
<img src="/images/foo.jpeg" loading="lazy" />
Si vous mettez à jour ou modifiez votre site en supprimant ou en modifiant ce
les utilisateurs qui affichent une version en cache de votre code HTML risquent de voir une erreur
une image est manquante, car l'élément /images/foo.jpeg d'origine est toujours en cache lorsque
lorsqu'ils reviennent sur votre site.
Soyez prudent, cela ne vous affectera peut-être pas. Mais globalement, il est important de rappelez-vous que votre site, lorsqu'il est mis en cache par vos utilisateurs finaux, n'existe plus seulement sur vos serveurs. Il peut plutôt exister dans des éléments à l'intérieur des caches des applications des navigateurs.
En général, la plupart des guides sur la mise en cache parleront de ce type de que vous souhaitiez mettre en cache pendant une heure, plusieurs heures, etc. Pour définir utilisez un en-tête comme celui-ci (qui est mis en cache pendant 3 600 secondes, heure):
Cache-Control: max-age=3600,immutable,public
Un dernier point. Si vous créez un contenu d'actualité qui n'est généralement les utilisateurs n'y ont pas eu accès une fois, comme des articles d'actualité. Je pense qu'ils ne devraient jamais être mis en cache, et vous devez utiliser la valeur par défaut adaptée ci-dessus. Je pense que nous avons souvent surestimer la valeur de la mise en cache plutôt que le désir d'un utilisateur de toujours voir les dernières et contenus de qualité, comme des nouvelles critiques sur un sujet d'actualité .
Options non HTML
Outre le HTML, d'autres options pour les fichiers qui se trouvent dans le milieu de terrain incluent:
En règle générale, recherchez les composants qui n'ont aucune incidence sur les autres.
- Par exemple, évitez d'utiliser le langage CSS, car il modifie la façon dont le code HTML rendu
Images volumineuses utilisées dans des articles d'actualité
- Vos utilisateurs ne consulteront probablement plus aucun article que de fois, alors ne mettez pas en cache les photos ou les images de héros indéfiniment et stockage des déchets
Un élément qui représente un élément qui lui-même a une durée de vie
- Il est possible que les données JSON sur la météo ne soient publiées que toutes les heures. vous pouvez mettre en cache le résultat précédent pendant une heure ; il ne changera pas dans votre fenêtre
- Les builds d'un projet Open Source peuvent être soumis à un débit limité. Par conséquent, mettez en cache un l'image d'état de compilation jusqu'à ce que l'état change
Résumé
Lorsque les utilisateurs chargent votre site une deuxième fois, vous avez déjà voté pour de confiance : ils veulent revenir et profiter davantage de ce que vous proposez. À cette adresse il ne s'agit pas toujours de réduire le temps de chargement de nombreuses options sont à votre disposition pour vous assurer que votre navigateur ne fait que le travail il doit offrir une expérience rapide et à jour.
La mise en cache n'est pas un nouveau concept sur le Web, mais elle requiert peut-être Valeur par défaut : envisagez d'utiliser une seule stratégie et activez fortement les meilleures stratégies de mise en cache quand vous en avez besoin. Merci de votre attention,
Voir aussi
Pour un guide général sur le cache HTTP, consultez Empêchez les requêtes réseau inutiles avec le cache HTTP.