20 Octobre 2022

En-têtes de cache HTTP

Meilleures pratiques pour gérer le cache de ressources statiques et utiliser les en-têtes de cache corrects en tant que Cache-Control.

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.

GET app.css, aucun objet trouvé dans le cache local

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-ages-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

Observation: 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-MatchIf-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 ETagLast-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-SinceIf-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.

Vous avez des doutes ? Vous ne savez pas par o√Ļ commencer ? Contactez-nous


Nous avons toutes les réponses à vos questions pour vous aider à faire le bon choix.

Discute avec nous

Discutez directement avec notre support avant-vente.

0256569681

Contactez-nous par téléphone pendant les heures de bureau 9h30 - 19h30

Contactez-nous en ligne

Ouvrez une demande directement dans l'espace contact.

INFORMATIONS

ManagedServer.it est le premier fournisseur italien de solutions d'hébergement hautes performances. Notre modèle d'abonnement est abordable et prévisible, afin que les clients puissent accéder à nos technologies d'hébergement fiables, à nos serveurs dédiés et au cloud. ManagedServer.it offre également d'excellents services d'assistance et de conseil sur l'hébergement des principaux CMS Open Source tels que WordPress, WooCommerce, Drupal, Prestashop, Magento.

JUSTE UN MOMENT !

Souhaitez-vous voir comment votre WooCommerce fonctionne sur nos syst√®mes sans avoir √† migrer quoi que ce soit ? 

Entrez l'adresse de votre site WooCommerce et vous obtiendrez une démonstration navigable, sans avoir à faire absolument quoi que ce soit et entièrement gratuite.

Non merci, mes clients préfèrent le site lent.
Remonter en haut