Pour gagner en vitesse, vous pouvez demander aux navigateurs internet de mettre en cache des ressources.
Par exemple, vous pouvez demander à mettre les ressources CSS, JS, images en cache.
Ainsi, lorsque le visiteur retourne sur le site, ces éléments sont pris dans le cache et non retélécharger.
Vous gagnez en rapidité mais aussi économisé la bande passante.
Les demandes de caches se font à partir du champs Cache Control dans le header d’une requête HTTP.
Pour cela, Nginx permet de configurer une mise en cache très fine.
Dans ce tutoriel, je vous explique comment configurer la mise en cache du navigateur internet avec le Cache Control sur Nginx.
Qu’est-ce que le cache du navigateur internet (Cache Control) ?
Le champs cache control est un champs dans l’en-tête de réponse du serveur WEB qui permet d’indiquer au navigateur internet comment il doit gérer la mise en cache d’une ressource.
Le délai de mise en cache se règle à partir d’un TTL (Time-To-Live).
L’administrateur d’un site peut donc déterminer combien de temps une page HTML, une ressources CSS, JavaScript doit rester en cache sur les navigateurs internet.
Le TTL contrôle combien de temps l’objet restera en 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, car vous pourriez changer quelque chose mardi.
Régler un âge maximal autour de quelques minutes pour votre page d’accueil est assez long pour couvrir les recharges immédiates, et assez rapide pour permettre une propagation rapide des mises à jour. Cependant, pour les ressources statiques comme les images, elles peuvent ne jamais changer, et vous devriez être bien en réglant des valeurs TTL élevées, même aussi élevées que deux ans.
Cela est donc important pour configurer une mise en cache efficace et rendre votre site le plus rapide possible.
Dans ce tutoriel, je vous montre quelques exemples pour implémenter la mise en cache dans Nginx.
Comment implémenter la mise en cache du navigateur avec le cache Control sur Nginx
avec add_header Cache-Control
C’est la méthode confidentielle pour configurer la mise en cache du navigateur internet avec Nginx.
Voici les types de cache possibles :
- 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
- Private : contient des données sensibles qui ne peuvent pas être mises en cache par un CDN ou proxys inversés. Le navigateur de l’utilisateur peut le mettre en cache localement. Utilisez-le 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 avec le serveur d’origine des mises à jour avant de l’utiliser Utilisez-le si vous souhaitez que l’utilisateur revalide à chaque fois
- no-store : désactive entièrement la mise en cache. Utilisez-le uniquement pour des données hautement sensibles qui ne doivent pas être envoyées deux fois
Puis on définit la directive max-age qui indique le TTL :
- -1, ou off, qui désactivera la mise en cache et ne modifiera pas les en-têtes existants
- Epoch, réglé sur Unix Time Zero, qui éteindra 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, pour les secondes
- 1m, pour les minutes
- 24h, pour les heures
- 3d, pour les jours
- 1M, pour les mois
- 2y, pour les années
Par exemple ci-dessous, on définit une mise en cache avec un TTL de 15552000 secondes, soit180 jours :
location ~* ^.+\.(xml|ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf|woff2|webp|webm)$ {
access_log off;
log_not_found off;
add_header Cache-Control "public, max-age=15552000";
}Ce qui donne :
- 1 heure :
max-age=3600 - 1 jour :
max-age=86400 - 1 semaine :
max-age=604800 - 1 mois :
max-age=2628000 - 1 année :
max-age=31536000
Puis vous pouvez vérifier le header et le champs Cache-Control avec curl ou tout autres méthodes : 4 façons d’afficher l’en-tête HTTP (headers) d’une page internet
curl -I -s http://localhost/demo.js HTTP/1.1 200 OK Server: nginx/1.18.0 (Ubuntu) Date: Fri, 01 Jul 2022 15:50:31 GMT Content-Type: application/javascript Content-Length: 13 Last-Modified: Fri, 01 Jul 2022 15:49:40 GMT Connection: keep-alive ETag: "62bf1794-d" Cache-Control: public, max-age=15552000 Accept-Ranges: bytes
D’autres directives sont possibles, par exemple :
- no-transform : désactive les conversions qui peuvent être effectuées sur la ressource. Par exemple, certains CDN compressent des images pour réduire la bande passante. Cette directive désactive ce comportement
- must-revalidate : indique au navigateur que chacune des ressources doit être revérifiée et si la version sur le serveur diffère de la version mise en cache, elle est fraîchement servie au navigateur. Cela ressemble donc à no-cache, la différence avec no-cache est que si le serveur ne peut délivrer la ressources, le navigateur WEB affichera une erreur 504 alors qu’avec no-cache, la version en cache du navigateur s’affiche
- s-maxage : indique également combien de temps la réponse est fraîche (similaire à l’âge maximum) – mais il est spécifique aux caches partagées, et ils ignoreront l’âge maximum lorsqu’il sera présent
- proxy-revalidate : équivalent à must-revalidate, mais spécifiquement pour les caches partagées uniquement
- must-understand : indique qu’un cache ne doit stocker la réponse que s’il comprend les exigences de mise en cache en fonction du code d’état
- immutable : La directive indique que la réponse ne sera pas mise à jour pendant qu’elle est fraîche
- stale-while-revalidate : indique que le cache pourrait réutiliser une réponse obsolète alors qu’elle le revient à un cache.
- stale-if-error : Indique que le cache peut réutiliser une réponse obsolète lorsqu’un serveur d’origine répond avec une erreur (500, 502, 503 ou 504).
add_header Cache-Control "public, must-validate";Pour plus de détails suivre cette documentation : https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control
avec expires
Expires est une directive qui vous permet d’activer ou désactive l’ajout ou la modification des champs d’en-tête de réponse «expire» et «Cache-Control» à condition que le code de réponse soit égal à 200, 201 (1.3.10), 204, 206, 301, 302, 303, 304, 307.
L’heure dans le champ «Expire» est calculée comme une somme de l’heure et de l’heure actuels spécifiés dans la directive. Si le paramètre modifié est utilisé (0,7,0, 0,6.32), le temps est calculé comme une somme du temps de modification du fichier et le temps spécifié dans la directive.
La syntaxe est la suivante :
expires [modified] time;
expires epoch | max | off;Par exemple pour définir le TTL maximale :
location ~* ^.+\.(xml|ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf|woff2|webp|webm)$ {
access_log off;
log_not_found off;
expires max;
}Cela va renvoyer l’en-tête suivante :
Cache-Control: max-age=315360000
Pour définir un cache de 5 mois :
expires 5M;Il est possible de mixer expires avec add_headers pour modifier le Cache-Control :
location ~* .(?:css|js)$ {
expires 1y;
add_header Cache-Control "public";
}Enfin vous pouvez mapper une variable afin de change le délai de cache selon le type MIME.
map $sent_http_content_type $expires {
default off;
application/pdf 42d;
~image/ max;
}
expires $expires;No-cache
La directive no-cache force la validation d’une ressources cachée.
Si la version du serveur est plus récente que celle du navigateur internet alors ce dernier mets à jour le cache.
Par exemple, renvoyer le header suivant :
add_header Cache-Control "max-age=0, no-store, no-cache";Surrogate-Control
L’en-tête de réponse Surrogate-Control permet aux serveurs d’origine de dicter la mise en cache par les CDN ou proxy inversés.
add_header Surrogate-Control "public, max-age=86400";
add_header Cache-Control "public, max-age=120";Liens
- Nginx : un serveur WEB rapide
- Protéger Nginx des attaques DoS et bruteforce
- Optimiser Nginx pour améliorer la vitesse des sites WEB
- Optimiser le cache de Nginx et fastcgi
- Configurer le cache FastCGI de Nginx
- Nginx : implémenter la mise en cache du navigateur avec le Cache Control
- Comment vider le cache Nginx
- Nginx : configurer un MicroCaching pour améliorer les performances
- Installer/Configurer le module Google PageSpeed pour optimiser vos sites WEB
- Optimiser PHP-FPM
- Comment accélérer et optimiser WordPress
- Cloudflare : comment protéger Nginx et WordPress des attaques DoS, piratages et bruteforce
- Comment fonctionne un serveur WEB
L’article Nginx : implémenter la mise en cache du navigateur avec le Cache Control est apparu en premier sur malekal.com.
0 Commentaires