Compression Gzip Nginx : Accélérez le Chargement de Votre Site Web

La compression Gzip de Nginx aide votre site web à charger plus rapidement en réduisant la taille des réponses textuelles avant leur transmission sur le réseau. Si vos pages incluent des fichiers HTML, CSS, JavaScript, JSON, XML ou SVG, la compression peut réduire la taille transférée sans modifier ce que les utilisateurs voient dans le navigateur.

L'objectif est simple : envoyer moins d'octets, réduire le temps d'attente et mieux utiliser la bande passante. Pour la plupart des sites en production, Gzip est l'un des gains de performance les plus faciles à activer en toute sécurité avec Nginx.

Comment Fonctionne la Compression Gzip dans Nginx

La compression Gzip se produit après que Nginx a sélectionné une réponse mais avant de l'envoyer au client. Le navigateur annonce sa prise en charge avec l'en-tête de requête Accept-Encoding. Si Gzip est activé et que le type de réponse correspond à votre configuration, Nginx compresse le corps et l'envoie avec Content-Encoding: gzip.

Cela fonctionne mieux pour les formats texte car ils contiennent des motifs répétés. Les templates HTML, les noms de classes CSS, les identifiants JavaScript et les clés JSON se compressent souvent très bien. Les images, vidéos, PDF et archives sont généralement déjà compressés, donc essayer de les gzipper peut gaspiller du CPU sans réduire significativement la taille du fichier.

Une configuration de base se place généralement dans le bloc http pour s'appliquer à tous les blocs serveur :

gzip on;
gzip_comp_level 5;
gzip_min_length 1024;
gzip_vary on;
gzip_proxied any;
gzip_types
    text/plain
    text/css
    text/xml
    application/json
    application/javascript
    application/xml
    application/rss+xml
    image/svg+xml;

La directive gzip on active la compression. gzip_types indique à Nginx quels types MIME compresser en plus du text/html par défaut. gzip_min_length évite de gaspiller du CPU sur de petites réponses, où l'en-tête Gzip pourrait annuler le bénéfice.

gzip_vary on ajoute un en-tête Vary: Accept-Encoding. Cela est important si votre site est derrière un CDN ou un cache partagé, car les caches doivent savoir que les versions compressée et non compressée sont des variantes différentes de la même URL.

Pour une base de performance Nginx plus large, vous pouvez également consulter Ajustement des performances Nginx.

Un détail qui surprend souvent : Nginx compresse toujours text/html lorsque Gzip est activé, donc text/html n'a pas besoin d'apparaître dans gzip_types. Si vous l'ajoutez quand même, Nginx peut avertir que le type MIME est en double. Cet avertissement est inoffensif, mais c'est un signe que la configuration a été copiée sans être nettoyée.

Choisir des Paramètres de Compression Sûrs

La plus grande erreur avec la compression Gzip de Nginx est de traiter le niveau de compression comme un bouton de volume. Plus élevé n'est pas toujours meilleur. Les niveaux Gzip vont généralement de 1 à 9. Le niveau 1 est le plus rapide mais compresse moins. Le niveau 9 compresse plus mais peut coûter nettement plus de CPU.

Pour de nombreux sites web, gzip_comp_level 4, 5 ou 6 est une plage pratique. Cela offre une bonne compression sans trop solliciter votre serveur. Si votre serveur Nginx gère un trafic élevé ou fonctionne sur une petite instance, évitez de passer directement au niveau 9.

De bons réglages par défaut ressemblent à ceci :

Utilisez gzip_comp_level 5 pour une configuration équilibrée.
Utilisez gzip_min_length 1024 pour que les petites réponses ignorent la compression.
Compressez les actifs textuels, pas les médias déjà compressés.
Gardez gzip_vary on lorsque des caches ou CDN sont impliqués.
Testez l'utilisation du CPU après avoir activé la compression.

Voici un scénario courant. Vous gérez un site de documentation avec de nombreuses pages CSS, JavaScript et HTML. Avant Gzip, une page charge 650 Ko d'actifs textuels. Après avoir activé la compression, la taille transférée peut chuter considérablement, tandis que le navigateur reçoit toujours les mêmes fichiers après décompression. Les utilisateurs sur des connexions plus lentes ressentent le plus l'amélioration.

Les gains ne sont pas toujours égaux sur tous les sites. Une page dominée par des images JPEG ne s'améliorera pas beaucoup avec Gzip. Un tableau de bord qui envoie de grandes réponses JSON peut s'améliorer beaucoup.

Pour les API, soyez plus délibéré. Compresser une petite réponse JSON comme {"ok":true} est généralement inutile. Compresser un résultat de recherche de 300 Ko ou une charge utile de rapport peut en valoir la peine. Si votre API renvoie des données privées et reflète des entrées contrôlées par l'utilisateur dans la même réponse, discutez des risques de compression avec l'équipe applicative avant de l'activer partout. Cela ne signifie pas "ne jamais compresser les API". Cela signifie que la compression appartient au même panier de révision que la mise en cache, les cookies et les en-têtes de réponse.

Comment Tester que Gzip Fonctionne

Après avoir modifié la configuration Nginx, testez la syntaxe avant de recharger :

nginx -t

Rechargez ensuite Nginx via votre gestionnaire de services ou votre processus de déploiement. Un rechargement est généralement suffisant car il s'agit d'un changement de configuration, pas d'un redémarrage complet du binaire.

Vous pouvez vérifier une réponse avec curl :

curl -I -H "Accept-Encoding: gzip" https://example.com/app.css

Recherchez cet en-tête :

Content-Encoding: gzip

Vérifiez également :

Vary: Accept-Encoding

Si vous ne voyez pas Content-Encoding: gzip, vérifiez le type MIME de la réponse. Par exemple, un fichier JavaScript servi en tant que text/plain peut encore se compresser si text/plain est inclus, mais une réponse API personnalisée utilisant un type de contenu inhabituel peut ne pas correspondre à votre liste gzip_types.

Les outils de développement du navigateur peuvent également aider. Ouvrez l'onglet Réseau, rechargez la page et inspectez les en-têtes de réponse et la taille transférée. La taille transférée doit être inférieure à la taille de la ressource non compressée pour les fichiers compressibles.

Si vous utilisez également un CDN, rappelez-vous que le CDN peut effectuer sa propre compression. Dans ce cas, Nginx peut ne pas être la couche finale qui décide ce que le navigateur reçoit. Testez à la fois l'accès direct à l'origine et l'URL publique du CDN lorsque c'est possible.

Si la réponse de l'origine directe est compressée mais que la réponse du CDN ne l'est pas, examinez les paramètres de compression du CDN et le comportement de la clé de cache. Si la réponse du CDN est compressée mais que l'origine ne l'est pas, cela peut être acceptable. De nombreuses équipes laissent intentionnellement le CDN gérer la compression statique publique tout en gardant la configuration de l'origine plus simple.

Quand Faire Attention avec Gzip

Gzip est sûr pour la plupart des contenus statiques et dynamiques, mais il y a des cas où vous devriez ralentir et tester soigneusement.

Ne compressez pas les fichiers déjà compressés. Les exemples courants incluent :

.jpg, .jpeg, .png et .webp
.mp4, .mov et autres formats vidéo
.zip, .gz, .tar.gz et archives
La plupart des fichiers de polices, selon le format et le chemin de livraison

Vous devez également surveiller l'utilisation du CPU. La compression n'est pas gratuite. Si votre serveur fonctionne déjà près de ses limites CPU, activer une compression agressive peut aggraver les temps de réponse sous charge. Commencez avec des paramètres modérés, puis surveillez le trafic, la latence et le CPU.

Les applications sensibles à la sécurité doivent également éviter d'exposer des secrets dans des réponses compressées à côté d'entrées contrôlées par l'attaquant. C'est un risque plus spécialisé, mais il est bon à connaître pour les applications qui reflètent les entrées utilisateur dans des pages contenant des jetons ou des données privées.

Pour les actifs statiques, une autre option est de précompresser les fichiers pendant votre pipeline de construction et de servir les versions .gz depuis le disque. Cela peut réduire le CPU d'exécution, en particulier pour les gros bundles JavaScript. Les réponses API dynamiques ont toujours besoin d'une compression à l'exécution si vous voulez qu'elles soient compressées.

Si vous servez des fichiers précompressés, activez gzip_static on; et assurez-vous que le fichier .gz est généré à partir de la même version exacte de l'actif que le fichier non compressé. Un app.js.gz obsolète à côté d'un app.js plus récent est un bogue frustrant : seuls les clients qui demandent Gzip voient l'ancien code.

gzip_static on;

Cette directive est utile pour les artefacts de construction, pas pour les réponses dynamiques en amont. Pour les réponses dynamiques proxyées depuis un serveur d'application, Nginx a toujours besoin d'une compression à l'exécution à moins que l'amont n'envoie déjà un corps compressé.

Quand Demander de l'Aide

Faites appel à un administrateur Nginx expérimenté ou à un ingénieur DevOps si l'activation de Gzip provoque une utilisation élevée du CPU, un comportement incohérent du CDN ou des réponses cassées pour les clients plus anciens. Vous devriez également demander de l'aide si les paramètres de compression sont mélangés dans plusieurs fichiers de configuration inclus et que vous n'êtes pas sûr du bloc réellement actif.

Pour un site web simple, Gzip peut être activé en quelques minutes. Pour une application à fort trafic, traitez-le comme tout changement de performance : testez-le, déployez-le progressivement et surveillez le résultat.

La compression Gzip de Nginx est un moyen pratique d'accélérer le chargement des sites et API à forte composante textuelle. Gardez les types MIME ciblés, choisissez un niveau de compression modéré et vérifiez les en-têtes après le rechargement. Une fois en place, les utilisateurs reçoivent des réponses plus petites tandis que votre code applicatif reste inchangé.