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

La mise en cache est la procédure de stockage des données téléchargées pour une utilisation ultérieure, où ils peuvent être lus à partir du disque au lieu de les redemander. L'utilisation appropriée de votre navigateur et de la mise en cache CDN peut considérablement accélérer votre portail Web.

Comment fonctionne la mise en cache?

Le navigateur de chaque utilisateur a un cache intégré, qui stocke les objets statiques téléchargés à partir de sites Web. La prochaine fois qu'ils se connectent, si l'objet qu'ils demandent est toujours dans le cache, sera chargé à partir de la mémoire au lieu de le redemander, ce qui accélérera considérablement les performances et réduira la charge sur votre serveur Web dans la procédure.

Le navigateur de l'utilisateur est un cache côté client. Malgré cela, 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 divers serveurs de périphérie situés dans le monde. Cela améliore la latence d'accès, performances et réduit considérablement le stress sur votre serveur Web. Pour plus d'informations sur les CDN, vous pouvez lire notre guide ici.

Cache-Control est un en-tête que vous pouvez configurer votre serveur Web pour ajouter à toutes les requêtes sortantes. Lors de son utilisation, vous pouvez spécifier quelles ressources sont mises en cache et pour combien de temps. Malgré cela, il y a quelques choses à faire attention avant de l'ajouter à l'ensemble du site.

Certaines pages devraient Jamais être mis en cache. Tout ce qui nécessite qu'un utilisateur se connecte ne doit pas être mis en cache par un CDN, sinon vous courrez le risque montrer les informations personnelles d'un utilisateur à d'autres. Vous pouvez toujours mettre en cache ces types de pages uniquement du côté du navigateur (Réglage Cache-Control pour private). En règle générale, si la page va être exactement la même pour tous les utilisateurs, comme page d'accueil, peut le mettre en cache. Ressources statiques, comme CSS et images, peut généralement être mis en cache, souvent plus longtemps.

Vous voudrez également vous assurer de déterminer des valeurs de durée de vie raisonnables. (TTL) pour chaque ressource. TTL contrôle combien de temps l'objet restera dans le cache avant d'être invalidé, ce qui incite 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, parce que je pourrais changer quelque chose mardi. Déterminer un âge maximum de quelques minutes pour votre page d'accueil est suffisamment long pour couvrir les rechargements immédiats et suffisamment rapide pour permettre une diffusion rapide des mises à jour.. Malgré cela, pour les ressources statiques comme les images, il est possible qu'ils ne changent jamais, et il devrait être bon de 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, tu peux le nommer styles-1.0.1.css, et le navigateur de l'utilisateur (et n'importe quel CDN devant lui) vous le verrez comme un nouveau fichier qui doit être téléchargé à nouveau. En même temps, pour certains CDN, vous pouvez émettre des remplacements manuels pour vider le cache existant sans modifier les noms de fichiers.

Comment utiliser Cache-Control dans NGINX

Cache-Control tu as des options:

• public – Tout le monde peut le mettre en cache, y compris les navigateurs et CDN. Utilisez ceci pour la plupart des objets statiques.
• private – Contient des données sensibles qui ne peuvent pas être mises en cache via des CDN ou des proxy inverses. Le navigateur de l'utilisateur peut le mettre en cache localement. Utilisez ceci pour la plupart des pages authentifiées.
• no-cache – Malgré le nom, ne pas désactiver la mise en cache. Le navigateur peut toujours mettre en cache la solution pour les performances, mais vous devez vérifier auprès du serveur d'origine les mises à jour avant de l'utiliser. Utilisez ceci si vous voulez que l'utilisateur revalide à chaque fois
• no-store – Désactiver complètement la mise en cache. Utilisez-le uniquement pour les données hautement confidentielles qui ne doivent pas être soumises deux fois.

Lors du réglage du max-age, toujours fait en quelques secondes. Malgré cela, NGINX permet d'autres valeurs personnalisées:

• -1, O off, qui désactivera la mise en cache et ne modifiera pas les en-têtes existants
• epoch, mis à l'heure Unix zéro, qui désactivera explicitement la mise en cache et purgera tous les caches (utile si vous utilisez NGINX comme proxy inverse)
• max, qui expirera à la fin de l'univers, les 31 de décembre à 2037
• 30s, pendant des secondes
• 1m, par minute
• 24h, Pendant des heures
• 3d, pendant des jours
• 1M, Pendant des mois
• 2y, pendant des années

En même temps, vous pouvez ajouter le no-transform directif, qui désactive toute conversion pouvant être effectuée 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:

expire 1et;
add_header Cache-Contrôle "Publique, pas de transformation";

La première ligne définit l'âge maximum dans 1 année et la seconde établit le public et no-transform paramètres de mise en cache. Vous pouvez l'ajouter à un server bloquer pour appliquer à l'échelle du site, mais une meilleure méthode consiste à faire correspondre les extensions de fichier à un bloc d'emplacement pour déterminer différentes valeurs en fonction de l'extension de fichier:

emplacement ~* .(?:css|js)$ {
  expire 1et;
  add_header Cache-Contrôle "Publique";
}

Ce bloc d'emplacement utilise une correspondance d'expression régulière, désigné 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 de localisation normal, qui aura la priorité sur une correspondance regex.

emplacement/profil {
    expire 2d;
    add_header Cache-Contrôle "Publique, pas de transformation";
}

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

Utilisez Surrogate-Control pour modifier le comportement du CDN

Bien que vous puissiez désactiver la mise en cache CDN tout en profitant de la mise en cache du navigateur en utilisant Cache-Control: private, il vaut mieux avoir un contrôle direct dessus. La plupart des CDN respecteront le Surrogate-Control entête, qui fonctionne exactement de la même manière que Cache-Control, sauf que c'est uniquement destiné au CDN. De cette façon, vous pouvez dire à Fastly de faire une chose et à l'utilisateur d'en faire une autre.

Et NGINX, vous devrez configurer cet en-tête manuellement et configurer le max-age valeur au lieu d'utiliser NGINX expires directif.

add_header Surrogate-Control "Publique, âge-max=86400";
add_header Cache-Contrôle "Publique, âge-max=120";

Vous voudrez certainement tester avec votre CDN pour vérifier que cela fonctionne.Surrogate-Control c'est assez nouveau et ce n'est pas universel.