Comment mettre en cache les ressources statiques avec Nginx

Pourquoi la mise en cache des ressources statiques est importante

Chaque fois qu'un utilisateur visite votre site web, son navigateur demande des dizaines de ressources statiques : fichiers CSS, JavaScript, images, polices, etc. Sans une mise en cache appropriée, chaque requête atteint votre serveur, augmentant les temps de chargement et la bande passante utilisée. Nginx, un serveur web haute performance, peut améliorer cela de manière spectaculaire en indiquant aux navigateurs de mettre en cache ces ressources localement et en les mettant en cache côté serveur.

Dans ce guide, vous apprendrez à configurer Nginx pour mettre en cache efficacement les ressources statiques, réduisant la latence et la charge serveur.

Comprendre la mise en cache navigateur vs la mise en cache côté serveur

Il existe deux principaux types de mise en cache pertinents ici :

• Cache navigateur : le navigateur stocke les ressources localement selon les en-têtes HTTP comme Cache-Control et Expires. Les visites suivantes chargent les ressources depuis le disque, évitant les requêtes réseau.
• Cache côté serveur : Nginx stocke les réponses en mémoire ou sur disque et les sert directement pour les requêtes répétées, réduisant la charge du backend.

Les deux sont essentiels pour la performance. Nous couvrirons les deux.

Étape 1 : Configurer le cache navigateur avec les en-têtes Expires

La façon la plus simple d'activer le cache navigateur est d'ajouter des directives expires à votre configuration Nginx. Cela définit les en-têtes Expires et Cache-Control.

Ouvrez le fichier de configuration de votre site (par exemple, /etc/nginx/sites-available/example.com) et ajoutez un bloc location pour les ressources statiques :

location ~* \.(css|js|jpg|jpeg|png|gif|ico|svg|woff|woff2|ttf|eot)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

Cela indique au navigateur de mettre en cache ces fichiers pendant un an. La directive immutable indique que le fichier ne changera jamais, donc le navigateur ne revalidera même pas lors du rechargement.

Bonne pratique : Utilisez des noms de fichiers versionnés (par exemple, style.abc123.css) afin de pouvoir mettre à jour les ressources sans casser le cache. Lorsque le fichier change, le nom du fichier change, et le navigateur récupère la nouvelle version.

Étape 2 : Activer le cache côté serveur avec le proxy cache

Si vous exécutez un serveur d'application (comme Node.js, Python ou PHP) derrière Nginx, vous pouvez mettre en cache les réponses statiques dans Nginx pour réduire les requêtes backend.

D'abord, définissez un chemin de cache dans le bloc http de nginx.conf :

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=static_cache:10m max_size=1g inactive=60m use_temp_path=off;

Ensuite, dans votre bloc server, utilisez-le :

location ~* \.(css|js|jpg|jpeg|png|gif|ico|svg)$ {
    proxy_cache static_cache;
    proxy_cache_valid 200 302 1y;
    proxy_cache_valid 404 1m;
    proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
    proxy_cache_lock on;
    add_header X-Cache-Status $upstream_cache_status;
    proxy_pass http://backend;
}

Cela met en cache les réponses réussies pendant un an et sert du contenu obsolète si le backend est indisponible. L'en-tête X-Cache-Status vous aide à déboguer (HIT, MISS, etc.).

Étape 3 : Optimiser avec la compression et HTTP/2

La mise en cache réduit les requêtes, mais vous pouvez encore accélérer les transferts en activant la compression gzip et HTTP/2.

Activez gzip dans nginx.conf :

gzip on;
gzip_types text/css application/javascript image/svg+xml;
gzip_min_length 1000;

HTTP/2 multiplexe les requêtes et s'active en ajoutant http2 à votre directive listen :

listen 443 ssl http2;

Remarque : HTTP/2 nécessite HTTPS. Si vous n'avez pas encore configuré TLS, consultez notre guide sur le fonctionnement de HTTPS et TLS.

Comparaison : Directives Cache-Control

Étape 4 : Tester et vérifier

Après avoir appliqué les modifications, rechargez Nginx : sudo nginx -s reload. Puis testez avec curl :

curl -I https://example.com/style.css

Recherchez les en-têtes Cache-Control et Expires. Vous pouvez également utiliser les DevTools du navigateur (onglet Network) pour voir si les ressources sont servies depuis le cache (Statut 200 ou 304).

Pour le cache côté serveur, surveillez l'en-tête X-Cache-Status.

Pièges courants et bonnes pratiques

• Ne pas mettre en cache le HTML : le HTML doit être dynamique ou avoir des temps de cache courts pour refléter les mises à jour.
• Utiliser le versioning : ajoutez des hashes aux noms de fichiers pour invalider le cache lorsque le contenu change.
• Définir un max-age approprié : un an est sûr pour les ressources versionnées.
• Surveiller la taille du cache : les caches côté serveur peuvent grossir ; définissez max_size et inactive.
• Envisager un CDN : pour une audience mondiale, un CDN peut mettre en cache les ressources plus près des utilisateurs.

FAQ

Comment savoir si mes ressources sont mises en cache ?

Vérifiez les en-têtes de réponse avec curl -I ou les DevTools du navigateur. Recherchez Cache-Control: public, max-age=31536000 et les en-têtes Expires. Dans les DevTools, la colonne Size affichera « (from disk cache) » pour les ressources mises en cache.

Quelle est la différence entre expires et Cache-Control ?

expires définit une date absolue, tandis que Cache-Control utilise des secondes relatives. Cache-Control est prioritaire dans les navigateurs modernes. La directive expires de Nginx définit les deux pour la compatibilité.

Puis-je mettre en cache du contenu dynamique ?

Oui, mais avec prudence. Utilisez proxy_cache avec des TTL courts et envisagez des clés de cache basées sur les cookies ou les en-têtes. Pour le contenu spécifique à l'utilisateur, utilisez private ou évitez la mise en cache.

Accélérez votre flux de travail avec TryQuickToolBox

Tout en optimisant les performances de votre site, vous pourriez avoir besoin de compresser des images ou des PDF. Essayez notre Compresseur d'images pour réduire la taille des images sans perte de qualité, en complément de votre stratégie de cache Nginx.