En-têtes de cache HTTP

Il existe de nombreux en-têtes HTTP différents qui peuvent être utilisés par votre site Web. Pour l'instant, nous allons nous concentrer sur un sous-ensemble spécifique de ceux-ci : les en-têtes de cache. Nous vous montrerons les détails concernant les en-têtes de cache, afin que vous sachiez comment les utiliser à l'avenir !

Dans le contexte des sites Web et des applications, la mise en cache est définie comme le stockage de contenu dans une mémoire temporaire, telle que celle du navigateur ou de l'appareil de l'utilisateur ou sur un serveur intermédiaire, afin de réduire le temps nécessaire pour accéder à ce fichier .

Selon HTTP Archive, parmi les 300.000 XNUMX meilleurs sites, le navigateur de l'utilisateur peut mettre en cache près de la moitié de tout le contenu téléchargé.

Réduit le temps nécessaire à l'utilisateur pour visualiser des images ou des fichiers Javascript ou CSS. En effet, l'utilisateur accède maintenant au fichier depuis son système au lieu d'être téléchargé depuis le réseau. Dans le même temps, la mise en cache réduit également le nombre de requêtes et de transferts de données depuis vos serveurs. Il s'agit sans aucun doute d'énormes économies pour les vues et les visites répétées de la page.

Comment fonctionne la mise en cache ?

Supposons que nous ouvrions une page Web https://www.example.com et que le serveur renvoie le code HTML suivant :

...
<link type="text/css" href="https://www.example.com/app.css" rel="stylesheet">
...
<!-- Rest of the HTML -->

Lorsque le navigateur analyse ce code HTML, il identifie qu'une ressource CSS doit être chargée à partir de https://www.example.com/app.css .

Le navigateur envoie une requête au serveur pour ce fichier, le serveur renvoie le fichier et indique également au navigateur de le mettre en cache pendant 30 jours. Plus loin dans ce guide, nous verrons comment le serveur envoie ces instructions au navigateur.

Maintenant, disons que vous ouvrez une autre page sur le même site Web après quelques heures. Le navigateur analyse à nouveau le code HTML et trouve également le même fichier CSS sur cette page : https://www.example.com/app.css . Étant donné que le navigateur dispose de cette ressource particulière dans son cache local, il n'ira même pas au serveur. La requête réseau n'est jamais faite, le fichier est accessible depuis le cache local et les styles sont appliqués très rapidement.

Comment est-il fait?

Il existe une gamme d'en-têtes de cache et de directives associées qui fournissent des instructions explicites à tout serveur d'utilisateur final, CDN et navigateur sur la façon de gérer le contenu mis en cache. La combinaison de plusieurs fonctionnalités peut vous donner les résultats souhaités ou empêcher le cache de fonctionner car elles ne sont pas utilisées correctement. Nous vous donnerons un aperçu rapide des en-têtes de cache HTTP les plus courants, de leurs directives et de la manière de les utiliser.

Cache-Control : directives

Plusieurs directives peuvent être utilisées pour contrôler la fonctionnalité des en-têtes de cache. Vous n'êtes pas obligé de les utiliser tous, alors choisissez ceux dont vous avez besoin et laissez les autres de côté. Voici les directives les plus importantes :

max-age

Dans la plupart des utilisations des en-têtes de contrôle de cache, vous verrez cette directive en cours d'utilisation. Indique la durée maximale en secondes pendant laquelle les réponses récupérées peuvent être réutilisées à partir du moment où une demande est faite. Par exemple: max-age=300indique qu'une ressource peut être réutilisée pendant les 300 prochaines secondes. Cette ressource peut être mise en cache par le navigateur ou par n'importe quel cache en aval du serveur pendant cette période.

s-maxage

Il s-le préfixe "" signifie partagé comme dans le cache partagé. Cette directive est explicitement pour CDN parmi d'autres caches intermédiaires. Cette directive prévaut sur max-agedirective et fait expirer le champ d'en-tête lorsqu'il est présent. Il est important de se rappeler que cette directive n'affectera pas les navigateurs des visiteurs. Vous pouvez donc utiliser différentes valeurs pour mag-agee s-maxagespécifier des temps de cache différents pour les visiteurs et les CDN.

Cela peut être utile, par exemple si vous utilisez des systèmes de mise en cache tels que Vernis et souhaitez demander au serveur de cache de définir un certain temps de cache pour certaines pages.

pas de cache

La no-cacheindique que les réponses renvoyées ne peuvent pas être utilisées pour des requêtes ultérieures vers la même URL avant de vérifier si les réponses du serveur ont été modifiées. Avec un ETag approprié (également appelé jeton de validation) présent, par conséquent, il se produit no-cacheun aller-retour pour tenter de valider les réponses mises en cache. Cependant, les caches peuvent supprimer les téléchargements si les ressources n'ont pas changé. Cela signifie que les navigateurs Web peuvent mettre en cache les actifs, mais doivent vérifier chaque demande si les actifs ont changé (le serveur renverra une réponse HTTP 304 si rien n'a changé).

sans magasin

Contrairement à no-cache, la no-storedirective est plus simple. En effet, cela empêche les navigateurs et tous les caches intermédiaires de stocker toute version des réponses renvoyées, telles que les réponses contenant des informations privées/personnelles ou des informations bancaires. Chaque fois que les utilisateurs demandent cet actif, les demandes sont envoyées au serveur. Les ressources sont téléchargées à chaque fois.

public

Si une réponse est marquée comme publique, elle peut être mise en cache même dans les cas où elle est associée à l'authentification HTTP ou si le code d'état de la réponse HTTP n'est normalement pas mis en cache. Étant donné que les informations de mise en cache explicites, telles que via le max-agedirective, montre qu'une réponse est toujours en cache, l'utilisation de cette directive n'est généralement pas nécessaire.

Dans la plupart des cas, une réponse marquée comme publique n'est pas nécessaire, car les informations de mise en cache explicites (par ex. max-age) montrent qu'une réponse peut toujours être mise en cache.

Privé

Une réponse marquée comme privée peut être mise en cache par le navigateur. Cependant, ces réponses sont généralement destinées à des utilisateurs uniques, elles ne peuvent donc pas être mises en cache à partir de caches intermédiaires (par exemple, les pages HTML contenant des informations utilisateur privées peuvent être mises en cache par le navigateur d'un utilisateur mais pas à partir d'un CDN).

expire

Il y a longtemps, cet en-tête était utilisé pour exploiter les mécanismes de mise en cache. Cet en-tête contient simplement un horodatage. Il est toujours utile pour les agents utilisateurs plus anciens, mais il est important de noter que le Cache-Control max-ageavoir s-maxageencore la priorité sur la plupart des systèmes modernes.

dernière modification

Cet en-tête est l'un des validateurs les plus courants pour le cache. Indique quand une ressource demandée a été modifiée pour la dernière fois. Bien qu'il soit l'un des validateurs les plus courants, ses origines remontent à l'ère HTTP / 1.0, ce qui en fait un validateur hérité.

étiqueter

Une nouvelle méthode de validation est l'utilisation d'ETag. C'est devenu la norme depuis HTTP/1.1. Ceci est validé via un champ d'en-tête ETag. Il est généralement basé sur un hachage du contenu demandé, mais ce n'est pas obligatoire. Cependant, le client qui en fait la demande ne doit pas savoir comment il est généré. Si un client a un objet dans son cache qui a expiré, il peut utiliser l'ETag pour envoyer une requête HTTP au serveur. Le serveur vérifiera ensuite ce jeton par rapport aux ressources mises en cache. Si le bien n'a pas été modifié, le serveur peut retourner une réponse 304 inchangée au client. Cela régénérera la durée de vie de la ressource mise en cache, au lieu de recharger la ressource.

Etag peut être un en-tête de validation de remplacement ou complémentaire à last-modified. Il peut être particulièrement utile de l'implémenter lorsqu'il s'agit d'en-têtes de dernière modification incorrects ou lorsqu'il est nécessaire de les désactiver en supprimant l'en-tête.

Voyons quelques cas pratiques

Tout type de mise en cache fonctionnerait normalement par mise à jour et validation. Expliquons ce que cela signifie. Les nouvelles demandes vous donneront généralement une nouvelle copie du contenu servi instantanément à partir du cache. Cependant, une représentation validée renverra rarement la copie entière si elle n'a pas changé depuis la dernière fois que vous l'avez demandée. Dans les cas où il n'y a pas de validateur présent (par exemple, un ETag ou un en-tête Last-Modified) combiné à un manque d'informations de fraîcheur, il sera généralement considéré comme non-cachable.

L'obtention d'une mise en cache appropriée offre d'énormes avantages en termes de performances, économise de la bande passante et réduit les coûts de serveur, mais de nombreux sites utilisent la moitié de la mise en cache, créant des conditions de concurrence entraînant une perte de synchronisation des ressources interdépendantes.

La grande majorité des meilleures pratiques de mise en cache relèvent de l'un des deux modèles suivants :

Schéma 1 : contenu immuable + max-age

Cache-Control: max-age = 31536000

• Le contenu de cette URL ne change jamais, donc...
• Le navigateur/CDN peut mettre en cache cette ressource pendant un an sans problème
• Le contenu en cache de moins de max-ageles secondes peuvent être utilisées sans consulter le serveur

Dans ce modèle, vous ne modifiez jamais le contenu d'une certaine URL, vous modifiez l'URL :

<script src="/script-f93bca2c.js"></script>
<link rel="stylesheet" href="/styles-a837cb1e.css" />
<img src="/cats-0e9a2ef4.jpg" alt="…" />

Chaque URL contient quelque chose qui change avec son contenu. Il peut s'agir d'un numéro de version, d'une date de modification ou d'un hachage du contenu, ce que je fais sur ce blog.

Cependant, ce modèle ne fonctionne pas pour des choses comme les articles et les billets de blog. Leurs URL ne peuvent pas être versionnées et leur contenu doit pouvoir changer. Sérieusement, étant donné les fautes de grammaire et d'orthographe de base que je fais, je dois pouvoir mettre à jour le contenu rapidement et fréquemment.

Schéma 2 : contenu éditable, toujours revalidé par le serveur

Contrôle de cache: no-cache

• Le contenu de cette URL peut changer, alors ...
• Toute version mise en cache localement n'est pas approuvée sans l'autorisation du serveur

Note: no-cache cela ne signifie pas "ne pas mettre en cache", cela signifie qu'il doit vérifier (ou "revalider" comme il l'appelle) avec le serveur avant d'utiliser la ressource mise en cache. no-storeindique au navigateur de ne pas le mettre en cache du tout. Aussi must-revalidatecela ne signifie pas "doit revalider", cela signifie que la ressource locale peut être utilisée si elle est plus jeune que celle fournie max-age, sinon il doit être revalidé. Oui je sais.

Dans ce modèle, vous pouvez ajouter un en-tête ETag(un ID de version de votre choix) ou un Last-Modifieddonnée en réponse. La prochaine fois que le client récupère la ressource, il renvoie la valeur du contenu qu'il possède déjà via If-None-Matche If-Modified-Sincerespectivement, permettant au serveur de dire "N'utilisez que ce que vous avez déjà, il est à jour" ou lorsque vous épelez "HTTP 304".

Si vous envoyez ETag/ Last-Modifiedce n'est pas possible, le serveur envoie toujours l'intégralité du contenu.

Ce modèle implique toujours une récupération du réseau, il n'est donc pas aussi bon que le modèle 1 qui peut complètement contourner le réseau.

Il n'est pas rare d'être rebuté par l'infrastructure nécessaire pour le modèle 1, mais également d'être rebuté par la demande de réseau requise par le modèle 2 et de choisir à la place quelque chose entre les deux : un max-agecontenu petit et variable. C'est un beau compromis.

max-age sur le changement de contenu est souvent le mauvais choix

… Et malheureusement ce n'est pas rare, par exemple cela arrive sur les pages de Github.

Imaginer:

• /article/
• /styles.css
• /script.js

... le tout servi avec :

Cache-Control : doit être revalidé, max-age = 600

• Le contenu des URL change
• Si votre navigateur a une version en cache de moins de 10 minutes, utilisez-la sans consulter le serveur
• Si ce n'est pas le cas, effectuez une récupération du réseau à l'aide de If-Modified-Sinceo If-None-Matchsi disponible

Ce modèle peut sembler fonctionner pendant les tests, mais il décompose les choses dans le monde réel et est vraiment difficile à retrouver. Dans l'exemple ci-dessus, le serveur avait en fait mis à jour le HTML, le CSS et le JS, mais la page s'est retrouvée avec l'ancien HTML et le JS du cache et le CSS mis à jour du serveur. L'incompatibilité de version a cassé les choses.

Souvent, lorsque nous apportons des modifications importantes au HTML, nous sommes susceptibles de modifier également le CSS pour refléter la nouvelle structure et de mettre à jour le JS pour s'adapter aux changements de style et de contenu. Ces ressources sont interdépendantes, mais les en-têtes de mise en cache ne peuvent pas l'exprimer. Les utilisateurs peuvent se retrouver avec la nouvelle version d'une/deux des ressources, mais l'ancienne version de l'autre(s).

max-ageil est relatif au temps de réponse, donc si toutes les ressources ci-dessus sont nécessaires dans le cadre de la même navigation, elles expireront à peu près au même moment, mais il y a toujours une petite chance d'une course là-bas. Si vous avez des pages qui n'incluent pas JS ou qui incluent des CSS différents, les dates d'expiration peuvent ne pas être synchronisées. Et pire, le navigateur supprime continuellement des éléments du cache et ne sait pas que HTML, CSS et JS sont interdépendants, il publiera donc volontiers l'un mais pas l'autre. Multipliez tout cela ensemble et il n'est pas improbable que vous vous retrouviez avec des versions incompatibles de ces ressources.

Pour l'utilisateur, cela peut entraîner des problèmes de mise en page et / ou de fonctionnalité. Des petits défauts au contenu totalement inutilisable.