Comment configurer les en-têtes de contrôle du 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 les redemander. 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 connectent, 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 dans le processus.

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 l'ajouter à toutes les demandes sortantes. En l'utilisant, vous pouvez spécifier quelles ressources sont mises en cache et pendant combien de temps. Il y a cependant quelques points à noter avant de l'ajouter à l'échelle du site.

Certaines pages devraient jamais être mis en cache. Tout ce qui oblige un utilisateur à se connecter 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 à 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 le CSS et les images, peuvent généralement être mises en cache, souvent beaucoup plus longtemps.

Vous voudrez également vous assurer de définir des valeurs de durée de vie (TTL) raisonnables pour chaque ressource. TTL contrôle la durée pendant laquelle 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 souhaitez pas mettre en cache votre page d'accueil pendant une année entière, car vous pourriez changer quelque chose mardi. La définition d'un âge maximal d'environ quelques minutes pour votre page d'accueil est suffisamment longue pour couvrir les recharges immédiates 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 bien définir des valeurs TTL élevées, même aussi élevées que 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.csset le navigateur de l'utilisateur (et tous les CDN en face de lui) le verront comme un nouveau fichier qui doit être téléchargé à nouveau. De plus, pour certains CDN, vous pouvez émettre des invalidations manuelles pour vider le cache existant sans changer de nom de fichier.

Comment utiliser Cache-Control dans NGINX

Cache-Control a quelques options:

• public – Peut être mis en cache par n'importe qui, y compris les navigateurs et les CDN. Utilisez ceci pour la plupart des objets statiques.
• private – Contient des données sensibles qui ne peuvent pas être mises en cache par les CDN ou les proxys 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, 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 ceci si vous voulez que l'utilisateur revalide à chaque fois
• no-store – Désactive complètement la mise en cache. Utilisez cette option uniquement pour les données hautement sensibles qui ne doivent pas être envoyées deux fois.

Lors du réglage du max-age, cela se fait toujours en quelques secondes. Cependant, NGINX autorise quelques valeurs personnalisées supplémentaires:

• -1, ou off, ce qui désactivera la mise en cache et ne modifiera pas les en-têtes existants
• epoch, défini sur l'heure Unix zéro, ce 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, le 31 décembre 2037
• 30s, pendant quelques secondes
• 1m, pendant quelques minutes
• 24h, Pendant des heures
• 3d, pendant des jours
• 1M, Pendant des mois
• 2y, pendant des années

De plus, vous pouvez ajouter le no-transform directive, 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 maximum sur 1 an et la seconde définit 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 avec un bloc d'emplacement pour définir des valeurs différentes en fonction de l'extension de fichier:

location ~* .(?:css|js)$ {
  expires 1y;
  add_header Cache-Control "public";
}

Ce bloc d'emplacement utilise une correspondance d'expression régulière, indiquée par le ~. Ceci est utile pour appliquer les paramètres généraux du 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.

location /profile {
    expires 2d;
    add_header Cache-Control "public, no-transform";
}

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

Utilisez Surrogate-Control pour modifier le comportement CDN

Bien que vous puissiez désactiver la mise en cache CDN tout en exploitant la mise en cache du navigateur en utilisant Cache-Control: private, il est préférable d’en avoir un contrôle direct. La plupart des CDN respecteront les Surrogate-Control en-tête, qui fonctionne exactement de la même manière que Cache-Control, sauf destiné uniquement aux CDN. 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 le max-age valeur au lieu d'utiliser les NGINX expires directif.

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 –Surrogate-Control est assez récent et n’est pas universel.