Comment implémenter la mise en cache du navigateur avec le module d’en-tête de Nginx sous CentOS 7

introduction

Plus un site Web est chargé rapidement, plus un visiteur est susceptible de rester. Lorsque les sites Web regorgent d'images et que le contenu interactif est géré par des scripts chargés en arrière-plan, l'ouverture d'un site Web n'est pas une tâche simple. Il consiste à demander un à un plusieurs fichiers différents au serveur. Minimiser le nombre de ces demandes est un moyen d’accélérer votre site Web.

Cela peut être fait de plusieurs manières, mais l'une des étapes les plus importantes à suivre est de configurerbrowser caching. Cela indique au navigateur que les fichiers téléchargés une fois peuvent être réutilisés à partir de copies locales au lieu de demander leur serveur encore et encore. Pour ce faire, de nouveaux en-têtes de réponse HTTP indiquant au navigateur comment se comporter doivent être introduits.

C’est là que le module d’entête de Nginx entre en jeu. Ce module peut être utilisé pour ajouter des en-têtes quelconques à la réponse, mais son rôle principal est de définir correctement les en-têtes de mise en cache. Dans ce didacticiel, nous verrons comment utiliser le module d’en-tête de Nginx pour implémenter la mise en cache du navigateur.

Conditions préalables

Pour suivre ce tutoriel, vous aurez besoin de:

En plus du module d’en-tête, nous utiliserons également le module Carte de Nginx dans cet article. Pour en savoir plus sur le module de carte, vous pouvez lireHow To Use Nginx’s map Module on CentOS 7.

[[step-1 -—- creating-test-files]] == Étape 1 - Création de fichiers de test

Dans cette étape, nous allons créer plusieurs fichiers de test dans le répertoire par défaut de Nginx. Nous utiliserons ces fichiers ultérieurement pour vérifier le comportement par défaut de Nginx, puis pour vérifier que la mise en cache du navigateur fonctionne.

Pour prendre une décision sur le type de fichier desservi sur le réseau, Nginx n’analyse pas le contenu du fichier; ce serait trop lent. Au lieu de cela, il recherche simplement l’extension du fichier pour déterminer leMIME type du fichier, ce qui indique l’objectif du fichier.

En raison de ce comportement, le contenu de nos fichiers de test n'est pas pertinent. En nommant les fichiers de manière appropriée, Nginx peut penser que, par exemple, un fichier entièrement vide est une image et un autre est une feuille de style.

Créez un fichier nommétest.html dans le répertoire Nginx par défaut en utilisanttruncate. Cette extension indique qu’il s’agit d’une page HTML.

sudo truncate -s 1k /usr/share/nginx/html/test.html

Créons quelques autres fichiers de test de la même manière: un fichier imagejpg, une feuille de stylecss et un fichier JavaScriptjs.

sudo truncate -s 1k /usr/share/nginx/html/test.jpg
sudo truncate -s 1k /usr/share/nginx/html/test.css
sudo truncate -s 1k /usr/share/nginx/html/test.js

L'étape suivante consiste à vérifier le comportement de Nginx en ce qui concerne l'envoi d'en-têtes de contrôle de mise en cache sur une nouvelle installation avec les fichiers que nous venons de créer.

[[step-2 -—- checking-the-default-behavior]] == Étape 2 - Vérification du comportement par défaut

Par défaut, tous les fichiers auront le même comportement de mise en cache par défaut. Pour explorer cela, nous allons utiliser le fichier HTML créé à l’étape 1, mais vous pouvez exécuter ces tests avec n’importe quel exemple de fichier.

Alors, vérifions sitest.html reçoit des informations concernant la durée pendant laquelle le navigateur doit mettre en cache la réponse. La commande suivante demande un fichier à notre serveur Nginx local et affiche les en-têtes de réponse.

curl -I http://localhost/test.html

Vous devriez voir plusieurs en-têtes de réponse HTTP:

Output: Nginx response headersHTTP/1.1 200 OK
Server: nginx/1.10.1
Date: Thu, 06 Oct 2016 10:21:04 GMT
Content-Type: text/html
Content-Length: 1024
Last-Modified: Thu, 06 Oct 2016 10:20:44 GMT
Connection: keep-alive
ETag: "57f6257c-400"
Accept-Ranges: bytes

Dans l'avant-dernière ligne, vous pouvez voir l'en-têteETag, qui contient un identifiant unique pour cette révision particulière du fichier demandé. Si vous exécutez la commandecurl précédente à plusieurs reprises, vous verrez exactement la même valeurETag.

Lors de l'utilisation d'un navigateur Web, la valeurETag est stockée et renvoyée au serveur avec l'en-tête de requêteIf-None-Match lorsque le navigateur souhaite demander à nouveau le même fichier - par exemple, lors de l'actualisation de la page.

Nous pouvons simuler ceci en ligne de commande avec la commande suivante. Assurez-vous de modifier la valeurETag dans cette commande pour qu'elle corresponde à la valeurETag de votre sortie précédente.

curl -I -H 'If-None-Match: "57f6257c-400"' http://localhost/test.html

La réponse sera maintenant différente:

Output: Nginx response headersHTTP/1.1 304 Not Modified
Server: nginx/1.10.1
Date: Thu, 06 Oct 2016 10:21:40 GMT
Last-Modified: Thu, 06 Oct 2016 10:20:44 GMT
Connection: keep-alive
ETag: "57f6257c-400"

Cette fois, Nginx répondra avec304 Not Modified. Il n’enverra plus le fichier sur le réseau; au lieu de cela, il dira au navigateur qu'il peut réutiliser le fichier qu'il a déjà téléchargé localement.

Ceci est utile car il réduit le trafic réseau, mais il n’est pas assez bon pour obtenir de bonnes performances de mise en cache. Le problème avecETag est que le navigateuralways envoie une requête au serveur pour lui demander s'il peut réutiliser son fichier mis en cache. Même si le serveur répond par un 304 au lieu d’envoyer le fichier à nouveau, il faut encore du temps pour faire la demande et recevoir la réponse.

Dans l'étape suivante, nous utiliserons le module d'en-têtes pour ajouter des informations de contrôle de mise en cache. Cela obligera le navigateur à mettre en cache localement certains fichiers sans demander explicitement au serveur s’il le souhaite.

[[step-3 -—- configuring-cache-control-and-expires-headers]] == Étape 3 - Configuration des en-têtes Cache-Control et Expires

En plus de l'en-tête de validation de fichierETag, il existe deux en-têtes de réponse de contrôle de mise en cache:Cache-Control etExpires. Cache-Control est la version la plus récente, qui a plus d'options queExpires et est généralement plus utile si vous voulez un contrôle plus fin sur votre comportement de mise en cache.

Si ces en-têtes sont définis, ils peuvent indiquer au navigateur que le fichier demandé peut être conservé localement pendant un certain temps (y compris pour toujours) sans qu'il soit à nouveau demandé. Si les en-têtes ne sont pas définis, les navigateurs demanderont toujours le fichier au serveur, en attendant des réponses200 OK ou304 Not Modified.

Nous pouvons utiliser le module en-tête pour définir ces en-têtes HTTP. Le module d’entête est un module principal de Nginx, ce qui signifie qu’il n’a pas besoin d’être installé séparément pour être utilisé.

Pour ajouter le module d’en-tête, ouvrez le fichier de configuration du bloc serveur par défaut Nginx dansvi (voici unshort introduction to vi) ou votre éditeur de texte préféré.

sudo vi /etc/nginx/nginx.conf

Trouvez le bloc de configurationserver, qui ressemble à ceci:

/etc/nginx/nginx.conf

. . .
server {
    listen 80 default_server;
    listen [::]:80 default_server;
. . .

Ajoutez ici les deux nouvelles sections suivantes: une avant le blocserver, pour définir la durée de mise en cache des différents types de fichiers, et une à l'intérieur, pour définir les en-têtes de mise en cache de manière appropriée.

Modifié /etc/nginx/nginx.conf

. . .
# Expires map
map $sent_http_content_type $expires {
    default                    off;
    text/html                  epoch;
    text/css                   max;
    application/javascript     max;
    ~image/                    max;
}

server {
    listen 80 default_server;
    listen [::]:80 default_server;

    expires $expires;
. . .

La section avant le blocserver est un nouveau blocmap qui définit le mappage entre le type de fichier et la durée pendant laquelle ce type de fichier doit être mis en cache.

Nous utilisons plusieurs paramètres différents dans cette carte:

  • La valeur par défaut est définie suroff, ce qui n'ajoutera aucun en-tête de contrôle de mise en cache. C’est une valeur sûre pour le contenu: nous n’avons aucune exigence particulière quant à la manière dont le cache devrait fonctionner.

  • Pourtext/html, nous définissons la valeur surepoch. Il s'agit d'une valeur spéciale qui aboutit explicitement à l'absence de mise en cache, ce qui oblige le navigateur à toujours demander si le site Web est à jour.

  • Pourtext/css etapplication/javascript, qui sont des feuilles de style et des fichiers Javascript, nous définissons la valeur surmax. Cela signifie que le navigateur mettra ces fichiers en cache aussi longtemps que possible, ce qui réduira considérablement le nombre de demandes, compte tenu du nombre important de ces fichiers.

  • Le dernier paramètre est pour~image/, qui est une expression régulière qui correspond à tous les types de fichiers contenantimage/ dans leur nomMIME type (commeimage/jpg etimage/png) . Comme les feuilles de style, il y a souvent beaucoup d'images sur les sites Web qui peuvent être mises en cache en toute sécurité, nous définissons donc cela surmax également.

À l'intérieur du bloc serveur, la directiveexpires (une partie du module headers) définit les en-têtes de contrôle de mise en cache. Il utilise la valeur de la variable$expires définie dans la carte. De cette façon, les en-têtes résultants seront différents selon le type de fichier.

Enregistrez et fermez le fichier pour quitter.

Pour activer la nouvelle configuration, redémarrez Nginx.

sudo systemctl restart nginx

Ensuite, assurons-nous que notre nouvelle configuration fonctionne.

[[step-4 -—- testing-browser-caching]] == Étape 4 - Test de la mise en cache du navigateur

Exécutez la même requête que précédemment pour le fichier HTML de test.

curl -I http://localhost/test.html

Cette fois, la réponse sera différente. Vous devriez voir deux en-têtes de réponse HTTP supplémentaires:

En-têtes de réponse Nginx

HTTP/1.1 200 OK
Server: nginx/1.10.1
Date: Thu, 06 Oct 2016 10:24:42 GMT
Content-Type: text/html
Content-Length: 1024
Last-Modified: Thu, 06 Oct 2016 10:20:44 GMT
Connection: keep-alive
ETag: "57f6257c-400"
Expires: Thu, 01 Jan 1970 00:00:01 GMT
Cache-Control: no-cache
Accept-Ranges: bytes

L'en-têteExpires affiche une date dans le passé etCache-Control est défini avecno-cache, ce qui indique au navigateur de toujours demander au serveur s'il existe une version plus récente du fichier (en utilisant leETag header, comme avant).

Vous verrez une différence de réponse avec le fichier image de test.

curl -I http://localhost/test.jpg

En-têtes de réponse Nginx

HTTP/1.1 200 OK
Server: nginx/1.10.1
Date: Thu, 06 Oct 2016 10:25:02 GMT
Content-Type: image/jpeg
Content-Length: 1024
Last-Modified: Thu, 06 Oct 2016 10:20:46 GMT
Connection: keep-alive
ETag: "57f6257e-400"
Expires: Thu, 31 Dec 2037 23:55:55 GMT
Cache-Control: max-age=315360000
Accept-Ranges: bytes

Dans ce cas,Expires affiche la date dans un futur lointain etCache-Control contient les informations demax-age, qui indiquent au navigateur combien de temps il peut mettre en cache le fichier en secondes. Cela indique au navigateur de mettre en mémoire l'image téléchargée le plus longtemps possible. Ainsi, toute apparition ultérieure de cette image utilisera le cache local et n'enverra aucune demande au serveur.

Le résultat devrait être similaire pourtest.js ettest.css, car les fichiers JavaScript et les feuilles de style sont également définis avec des en-têtes de mise en cache.

Cela signifie que les en-têtes de contrôle du cache ont été configurés correctement et que votre site Web bénéficiera du gain de performances et de moins de demandes du serveur en raison de la mise en cache du navigateur. Vous devez personnaliser les paramètres de mise en cache en fonction du contenu de votre site Web, mais les valeurs par défaut de cet article constituent un point de départ raisonnable.

Conclusion

Le module des en-têtes peut être utilisé pour ajouter des en-têtes quelconques à la réponse, mais la définition correcte des en-têtes de contrôle de mise en cache est l'une de ses applications les plus utiles. Il améliore les performances des utilisateurs du site Web, en particulier sur les réseaux à latence élevée, tels que les réseaux d’opérateurs mobiles. Cela peut également conduire à de meilleurs résultats sur les moteurs de recherche qui prennent en compte les tests de vitesse dans leurs résultats. La définition des en-têtes de mise en cache du navigateur est l’une des principales recommandations des outils de test PageSpeed ​​de Google.

Des informations plus détaillées sur le module des en-têtes peuvent être trouvéesin Nginx’s official headers module documentation.

Related