Comment configurer les en-têtes de contrôle de cache dans NGINX

La mise en cache est le processus de stockage des données téléchargées pour une utilisation ultérieure, où elles peuvent être lues à partir du disque plutôt que de demander le refaire. Utiliser correctement votre navigateur et la mise en cache CDN peut accélérer considérablement votre site Web.

Comment fonctionne la mise en cache ?

Le navigateur de chaque utilisateur dispose d'un cache intégré, qui stocke les objets statiques téléchargés à partir de sites Web. La prochaine fois qu'ils se connecteront, si l'objet qu'ils demandent est toujours dans le cache, il se chargera à partir de la mémoire plutôt que de le demander à nouveau, ce qui accélérera considérablement les performances et réduira la charge sur votre serveur Web au cours du processus.< /p>

Le navigateur de l'utilisateur est un cache côté client. Cependant, de nombreux grands sites utiliseront également un réseau de diffusion de contenu, ou CDN. Le CDN se trouve devant votre serveur Web et met en cache vos pages côté serveur, généralement sur plusieurs serveurs périphériques situés dans le monde entier. Cela améliore la latence d'accès, les performances et réduit considérablement le stress sur votre serveur Web. Si vous souhaitez en savoir plus sur les CDN, vous pouvez lire notre guide à leur sujet ici.

Cache-Control est un en-tête que vous pouvez configurer votre serveur Web pour ajouter à toutes les requêtes sortantes. En l'utilisant, vous pouvez spécifier quelles ressources doivent être mises en cache et pendant combien de temps. Il y a quelques points à noter cependant avant de l'ajouter à l'ensemble du site.

Certaines pages ne doivent jamais être mises en cache. Tout ce qui nécessite qu'un utilisateur se connecte ne doit pas être mis en cache par un CDN, sinon vous risquez d'afficher les informations personnelles d'un utilisateur à d'autres. Vous pouvez toujours mettre en cache ces types de pages uniquement du côté du navigateur (en définissant Cache-Control sur private). En règle générale, si la page doit être exactement la même pour tous les utilisateurs, comme votre page d'accueil, vous pouvez la mettre en cache. Les ressources statiques, comme les CSS et les images, peuvent généralement être mises en cache, souvent beaucoup plus longtemps.

Publicité

Vous voudrez également vous assurer que vous définissez des valeurs de durée de vie (TTL) raisonnables pour chaque ressource. TTL contrôle combien de temps l'objet restera dans le cache avant d'être invalidé, invitant l'utilisateur à demander un nouvel objet. Le compromis ici est entre un long temps de mise en cache et des mises à jour rapides. Vous ne voulez pas mettre en cache votre page d'accueil pendant une année entière, car vous pourriez changer quelque chose mardi. Définir un âge maximum d'environ quelques minutes pour votre page d'accueil est suffisamment long pour couvrir les rechargements immédiats et suffisamment rapide pour permettre une propagation rapide des mises à jour. Cependant, pour les ressources statiques telles que les images, elles peuvent ne jamais changer, et vous devriez pouvoir définir des valeurs TTL élevées, même jusqu'à deux ans.

Vous pouvez toujours utiliser des noms de fichiers versionnés pour déclencher un rechargement du cache. Si vous publiez une nouvelle version d'une feuille de style CSS, vous pouvez la nommer styles-1.0.1.css, et le navigateur de l'utilisateur (et tous les CDN qui la précèdent) la verra comme un nouveau fichier qui a besoin à retélécharger. De plus, pour certains CDN, vous pouvez émettre des invalidations manuelles pour vider le cache existant sans modifier aucun nom de fichier.

Comment utiliser Cache-Control dans NGINX

Cache-Control propose plusieurs options :

  • public – Peut être mis en cache par n'importe qui, y compris les navigateurs et les CDN. Utilisez-le pour la plupart des objets statiques.
  • privé – Contient des données sensibles qui ne peuvent pas être mises en cache par les CDN ou les proxy inverses. Le navigateur de l'utilisateur peut le mettre en cache localement. Utilisez-le pour la plupart des pages authentifiées.
  • pas de cache – Malgré son nom, il ne désactive pas la mise en cache. Le navigateur peut toujours mettre en cache la réponse pour les performances, mais doit vérifier auprès du serveur d'origine les mises à jour avant de l'utiliser. Utilisez-le si vous souhaitez que l'utilisateur revalide à chaque fois
  • no-store – Désactive complètement la mise en cache. Utilisez-le uniquement pour les données très sensibles qui ne doivent pas être envoyées deux fois.

Lors du réglage de l'âge maximal, cela se fait toujours en quelques secondes. Cependant, NGINX permet quelques valeurs personnalisées supplémentaires :

  • -1, ou off, qui désactivera la mise en cache et ne modifiera pas les en-têtes existants
  • epoch, défini sur Unix time zero, qui désactivera explicitement la mise en cache et purgera tous les caches (utile si vous utilisant NGINX comme proxy inverse)
  • max, qui expirera à la fin de l'univers, le 31 décembre 2037
  • 30s, pendant secondes
  • 1m , pendant des minutes
  • 24h, pendant des heures
  • 3j, pendant des jours
  • 1M, pendant des mois
  • 2y, pendant des années

De plus, vous pouvez ajouter la directive de non-transformation, qui désactive toutes les conversions pouvant être effectuées sur la ressource. Par exemple, certains CDN compressent les images pour réduire la bande passante. Cette directive désactive ce comportement.

Pour NGINX, vous pouvez modifier les en-têtes Cache-Control avec les directives suivantes :

expires 1y ; add_header Cache-Control “public, no-transform” ;

La première ligne définit l'âge maximal à 1 an, et la seconde définit les paramètres de mise en cache publique et sans transformation. Vous pouvez l'ajouter à un bloc de serveur pour l'appliquer à l'ensemble du site, mais une meilleure méthode consiste à faire correspondre les extensions de fichier avec un bloc d'emplacement pour définir des valeurs différentes en fonction de l'extension de fichier :

emplacement ~* .(?:css| js)$ { expire 1y; add_header Cache-Control “public” ; } Publicité

Ce bloc d'emplacement utilise une correspondance d'expression régulière, indiquée par le ~. Ceci est utile pour appliquer des paramètres généraux pour le type de contenu. Si vous souhaitez faire des exceptions pour des emplacements spécifiques, vous pouvez utiliser un bloc d'emplacement normal, qui aura la priorité sur une correspondance regex.

emplacement/profil { expire 2j; add_header Cache-Control “public, no-transform” ; }

Vous pouvez également utiliser le = modificateur, qui correspond exactement aux chemins et aura la priorité sur une correspondance regex et un bloc de localisation standard.

Utilisez Surrogate-Control pour modifier le comportement du CDN

Bien que vous puissiez désactiver la mise en cache CDN et continuer à tirer parti de la mise en cache du navigateur en utilisant Cache-Control: private, il est préférable d'avoir un contrôle direct sur celui-ci. La plupart des CDN respecteront l'en-tête Surrogate-Control, qui fonctionne exactement de la même manière que Cache-Control, sauf pour les CDN uniquement. De cette façon, vous pouvez dire à Fastly de faire une chose et à l'utilisateur d'en faire une autre.

Dans NGINX, vous devrez définir cet en-tête manuellement et définir la valeur d'âge max au lieu de en utilisant la directive d'expiration de NGINX.

add_header Surrogate-Control “public, max-age=86400” ; add_header Cache-Control “public, max-age=120” ;

Vous voudrez certainement tester avec votre CDN pour vérifier que cela fonctionne & #8212;Contrôle de substitution est assez récent et n'est pas universel.


Posted

in

by

Tags: