Skip to content

Tout pour WordPress, le développement web — et plus encore

⚙️ Comment activer la compression GZIP dans WordPress : un guide complet

⚙️ Comment activer la compression GZIP dans WordPress : un guide complet

Le site met 4 secondes à s’ouvrir et le visiteur s’en va. Cela vous semble familier? Le plus souvent, le problème ne vient ni de l’hébergement ni des images. Les pages pèsent simplement plus lourd qu’elles ne le devraient parce que le serveur les délivre «en l’état», sans compression.

La compression GZIP réduit la taille du HTML, du CSS et du JavaScript de 60 à 80% avant leur envoi vers le navigateur. Pour WordPress, il ne s’agit pas d’une extension lourde avec une multitude de réglages, mais d’une directive dans la configuration ou d’une case à cocher dans l’administration. Selon W3Techs, la compression est utilisée par plus de 85% des sites web sur Internet, et si le vôtre n’en fait pas partie, vous perdez des positions dans les moteurs de recherche et des conversions sans aucune raison.

Voici sept méthodes efficaces pour activer GZIP: de la modification manuelle du fichier.htaccess à quelques clics dans une extension. À la fin, je vous montrerai comment vérifier le résultat et passerai en revue les questions courantes sur la compatibilité avec les CDN, Brotli et la mise en cache.

💡 Aperçu rapide:

  • Ajouter le code de compression au fichier .htaccess via FTP
  • Écrire gzip on et gzip_types dans nginx.conf
  • Activer la compression avec une case à cocher dans W3 Total Cache ou WP Rocket
  • Vérifier le résultat dans Chrome DevTools ou sur GiftOfSpeed

Qu’est-ce que la compression GZIP et pourquoi un site WordPress en a-t-il besoin

GZIP est un algorithme de compression qui opère au niveau du serveur: avant l’envoi vers le navigateur, il «compacte» les fichiers texte sous une forme plus légère. Le navigateur les décompresse à la volée et affiche la page comme d’habitude. L’utilisateur ne perçoit aucune différence, tandis que le volume de données transmises est réduit de plusieurs fois.

Schéma de compression GZIP navigateur serveur

Ce qui est concrètement compressé: le code HTML des pages, les feuilles de style CSS, les scripts JavaScript, les fichiers XML, les polices et le SVG. GZIP ne touche pas aux images; il existe pour elles des formats de compression distincts (WebP, AVIF) et des extensions d’optimisation.

La différence en chiffres est facile à constater dans Chrome DevTools: la même page avant et après compression voit sa taille divisée par deux ou trois. Multipliez cela par le nombre de visiteurs par mois et vous obtenez une économie significative de trafic et de temps de chargement.

Une nuance importante: GZIP n’est pas la seule option. Les serveurs modernes prennent en charge Brotli, un algorithme de Google qui compresse les fichiers texte 15 à 25% mieux que GZIP. Mais Brotli n’est pas disponible chez tous les hébergeurs, alors que GZIP fonctionne partout, y compris sur les configurations les plus anciennes. Il est donc toujours pertinent de commencer par GZIP, et d’ajouter Brotli dans un second temps, une fois la base en place.

Méthode 1: via le fichier.htaccess sur Apache

Le scénario le plus courant: le site tourne sous Apache, et il vous suffit d’ajouter quelques lignes au fichier .htaccess situé à la racine du site.

Où se trouve le fichier.htaccess. Connectez-vous au serveur en FTP (par exemple avec FileZilla) ou accédez au gestionnaire de fichiers de l’hébergement. Dans le dossier racine du site (là où se trouvent wp-config.php et les dossiers wp-content, wp-admin), repérez le fichier .htaccess. Téléchargez-le sur votre ordinateur; nous allons le modifier en local afin de pouvoir revenir rapidement en arrière en cas d’erreur.

Ce qu’il faut ajouter. Ouvrez le fichier .htaccess dans un éditeur de texte (Notepad++, VS Code, Sublime Text) et ajoutez le bloc suivant AVANT les lignes # BEGIN WordPress:

1<IfModule mod_deflate.c>
2 AddOutputFilterByType DEFLATE text/html text/css text/javascript
3 AddOutputFilterByType DEFLATE application/javascript application/x-javascript
4 AddOutputFilterByType DEFLATE application/rss+xml application/xml application/xhtml+xml
5 AddOutputFilterByType DEFLATE image/svg+xml image/x-icon
6 AddOutputFilterByType DEFLATE font/ttf font/otf font/opentype application/x-font-ttf
7 AddOutputFilterByType DEFLATE application/vnd.ms-fontobject
8
9 BrowserMatch ^Mozilla/4 gzip-only-text/html
10 BrowserMatch ^Mozilla/4.0[678] no-gzip
11 BrowserMatch bMSIE !no-gzip !gzip-only-text/html
12 Header append Vary User-Agent
13</IfModule>
Fichier htaccess avec code de compression GZIP

Ce qui se passe ici. Le bloc <IfModule mod_deflate.c> vérifie si le module mod_deflate est activé sur le serveur (il l’est par défaut chez la plupart des hébergeurs). Les directives AddOutputFilterByType DEFLATE précisent quels types de fichiers compresser. Les lignes BrowserMatch sont une rustine pour les anciennes versions d’Internet Explorer qui évite les bogues de gzip sous IE6 et versions antérieures. Header append Vary User-Agent indique aux serveurs proxy de tenir compte du navigateur de l’utilisateur lors de la mise en cache.

Enregistrez le fichier et renvoyez-le sur le serveur en remplacement. Avant cela, assurez-vous de faire une copie de sauvegarde du fichier .htaccess d’origine; si le site tombe, il suffit de remettre l’ancienne version et tout fonctionnera comme avant.

Si, après l’envoi, le site affiche une erreur 500, vérifiez qu’il n’y a pas d’espaces superflus ou de sauts de ligne avant <?php ou après les balises fermantes dans le fichier. Une erreur dans le fichier .htaccess casse l’ensemble du site, il est donc préférable de procéder modification par modification et de vérifier après chacune.

Méthode 2: sur un serveur NGINX

NGINX gère la compression différemment d’Apache. Il n’y a pas de fichier .htaccess ici, et tous les réglages s’écrivent dans le fichier nginx.conf ou dans le fichier de configuration du site concerné (généralement dans /etc/nginx/sites-available/).

Ajoutez ou décommentez les lignes suivantes dans la section http ou server:

1gzip on;
2gzip_vary on;
3gzip_min_length 1000;
4gzip_comp_level 6;
5gzip_types text/plain text/css text/javascript
6 application/javascript application/x-javascript
7 application/rss+xml application/xml application/xhtml+xml
8 image/svg+xml image/x-icon
9 font/ttf font/otf application/x-font-ttf
10 application/vnd.ms-fontobject;
11gzip_disable "MSIE [1-6]\.(?!.*SV1)";

Après avoir effectué les modifications, vérifiez la syntaxe de la configuration avec la commande nginx -t et rechargez NGINX: sudo systemctl reload nginx.

Le paramètre gzip_comp_level 6 est un compromis entre le taux de compression et la charge du processeur. Une valeur de 1 correspond à une compression minimale, 9 à une compression maximale. En pratique, le niveau 6 offre quasiment le même gain que le niveau 9 tout en consommant nettement moins de ressources serveur.

Méthode 3: sur un serveur IIS (Windows Server)

IIS est le serveur web de Microsoft utilisé sur les hébergements Windows. L’activation de la compression se fait ici de deux manières: via l’interface graphique ou en ligne de commande.

Via l’interface IIS. Ouvrez le Gestionnaire IIS. Dans la section «Composants» → «Services», recherchez «Compression». Cochez les cases «Activer la compression de contenu statique» et «Activer la compression de contenu dynamique». Dans le panneau «Actions», cliquez sur «Appliquer».

En ligne de commande (en tant qu’administrateur):

1:: Static compression
2appcmd set config /section:urlCompression /doStaticCompression:True
3
4:: Dynamic compression
5appcmd set config /section:urlCompression /doDynamicCompression:True

La compression statique met en cache sur le disque des versions déjà compressées des fichiers, ce qui économise du temps processeur. La compression dynamique compresse les réponses «à la volée» et convient aux pages personnalisées, mais sollicite le processeur. En pratique, pour WordPress, les deux modes sont activés: le mode statique prend en charge le CSS/JS tandis que le mode dynamique gère le HTML de chaque page.

Méthode 4: via le panneau de l’hébergeur

La plupart des hébergeurs modernes activent GZIP par défaut. Si vous êtes sur cPanel, rendez-vous dans la section «Optimisation du site» ou «Performance» et cherchez l’option «Compression» ou «Compresser le contenu». Sur Plesk, le chemin est similaire: «Performance» → «Compression de la sortie».

Si vous ne trouvez pas l’option, écrivez au support de votre hébergement. C’est une demande standard; le support technique y répond en quelques minutes et active souvent la compression au niveau du serveur en une seule réponse. Vous n’avez pas besoin d’expliquer ce qu’est GZIP; il suffit d’écrire «Veuillez activer la compression GZIP pour mon site».

Vous pouvez vérifier si l’hébergement compresse déjà les pages avant toute modification; la méthode est décrite dans la section «Comment vérifier si la compression est activée» ci-dessous. Si la vérification montre que GZIP fonctionne, passez toutes les méthodes serveur et ne recourez aux extensions que si vous souhaitez gérer la compression depuis l’administration WordPress.

Méthode 5: l’extension W3 Total Cache

W3 Total Cache est l’un des plus anciens plugins de cache du dépôt WordPress, avec un million d’installations actives et une note de 4,5 sur WordPress.org. La compression GZIP s’y active via une simple case à cocher, sans avoir à modifier les fichiers du serveur.

Paramètres de compression HTTP dans W3 Total Cache

Installez le plugin depuis le dépôt WordPress, allez dans Performance → Browser Cache et repérez la section «HTTP (gzip) compression». Cochez la case «Enable HTTP (gzip) compression» et enregistrez les paramètres. Le plugin ajoutera automatiquement les directives nécessaires au fichier .htaccess ou configurera les règles NGINX selon le serveur sur lequel tourne le site.

  • Avantages: ne nécessite pas de modifier manuellement les fichiers du serveur, un million d’installations confirme sa stabilité, compatible CDN et Brotli
  • Inconvénients: interface surchargée d’options, un débutant peut facilement casser la mise en cache en cochant la mauvaise case

Méthode 6: l’extension WP Rocket

WP Rocket est une extension de performance premium qui ajoute automatiquement les règles GZIP dans le fichier .htaccess après activation. Elle ne comporte aucun réglage de compression; celle-ci est activée automatiquement dès l’installation.

  • Avantages: aucun travail manuel, la compression est activée automatiquement, l’extension résout aussi un ensemble de tâches connexes (cache, lazy loading, minification)
  • Inconvénients: payante (à partir de 59 $ par an), surpayer uniquement pour la compression GZIP ne se justifie pas

Si vous avez déjà acheté WP Rocket pour d’autres tâches, la compression fonctionne déjà. Si vous envisagez d’acquérir l’extension seulement pour la compression GZIP, ne le faites pas: le fichier .htaccess ou W3 Total Cache font la même chose gratuitement.

Méthode 7: l’extension WP Super Cache

WP Super Cache est une extension de cache gratuite d’Automattic (l’équipe à l’origine de WordPress.com). Elle fonctionne de manière plus simple que W3 Total Cache: moins de réglages, moins de risques de casser quelque chose.

Paramètres de compression dans WP Super Cache

Installez l’extension, allez dans Réglages → WP Super Cache → Avancé et trouvez l’option «Compresser les pages afin qu’elles soient servies plus rapidement aux visiteurs». Activez-la et enregistrez.

  • Avantages: gratuite, interface simple, code stable signé Automattic
  • Inconvénients: moins performante que W3 Total Cache sur les fonctionnalités de cache, pas de réglage fin des types de compression

Comment fonctionne la compression GZIP en pratique

Quand un navigateur demande une page, il envoie l’en-tête Accept-Encoding: gzip, deflate, br, ce qui signifie «je comprends gzip, deflate et brotli, envoyez la réponse dans l’un de ces formats». Le serveur voit cet en-tête, vérifie si la compression est activée pour le type de fichier demandé et, si c’est le cas, compresse la réponse et ajoute l’en-tête Content-Encoding: gzip.

Le navigateur reçoit les données compressées, les décompresse en mémoire et affiche la page. Pour l’utilisateur, tout se passe instantanément; la décompression gzip prend une fraction de milliseconde, même sur un appareil mobile peu puissant.

Ce mécanisme est universel: il fonctionne de la même manière pour Apache, NGINX, IIS et toutes les extensions WordPress. Les extensions n’inventent pas leur propre méthode de compression; elles ajoutent simplement les mêmes directives serveur que nous avons écrites manuellement dans les trois premières méthodes.

Ce qu’affichent Google PageSpeed Insights et GTmetrix

Les deux services, PageSpeed Insights et GTmetrix, vérifient la compression lors de chaque audit et signalent explicitement le problème si des ressources textuelles sont servies sans GZIP.

Avertissement de compression dans Google PageSpeed Insights

Dans PageSpeed Insights, l’avertissement apparaît sous la forme «Activer la compression de texte» dans la section «Opportunités» de l’audit. Lighthouse (le moteur de PageSpeed Insights) estime directement les gains potentiels en kilo-octets pour chaque ressource non compressée. Dans GTmetrix, il existe un contrôle similaire, «Activer la compression GZIP», dans la catégorie «Contenu».

Un point important: ni PageSpeed Insights ni GTmetrix ne font la distinction entre GZIP et Brotli au niveau des recommandations. Si la compression est activée par l’une ou l’autre de ces méthodes, l’audit affiche une coche verte. La compression GZIP suffit donc pour passer l’audit.

Comment vérifier si la compression est activée

Trois méthodes, de la plus visuelle à la plus bas niveau.

Méthode 1: Chrome DevTools. Ouvrez le site, appuyez sur F12, allez dans l’onglet Network. Actualisez la page, cliquez sur une ligne quelconque et consultez l’onglet Headers. Repérez la ligne Content-Encoding: gzip dans la section Response Headers.

En-tête Content-Encoding gzip dans Chrome DevTools

Vous pouvez également y voir la taille réelle et la taille compressée: dans l’exemple ci-dessus, la page pesait 51,6 Ko et, après compression, 17,7 Ko.

Comparaison de taille de fichier avant et après compression dans Chrome DevTools

Méthode 2: testeurs en ligne. GiftOfSpeed GZIP Test (giftofspeed.com/gzip-test) ou Check GZIP Compression (checkgzipcompression.net): vous collez l’URL et obtenez un verdict ainsi que le pourcentage de compression. Plus rapide que DevTools si vous devez vérifier le site de quelqu’un d’autre ou plusieurs pages à la suite.

Méthode 3: curl en ligne de commande. Si vous êtes sous Linux/macOS ou dans WSL sous Windows:

1curl -I -H &quot;Accept-Encoding: gzip&quot; https://yoursite.com | grep Content-Encoding

Une réponse contenant Content-Encoding: gzip signifie que la compression fonctionne. Une réponse vide signifie qu’elle ne fonctionne pas.

Courte explication en vidéo

Pour clore le sujet par une approche visuelle, voici une courte vidéo qui montre l’ensemble du processus d’activation de GZIP via .htaccess et la vérification du résultat dans Chrome DevTools:

⁉️🤔 Foire aux questions

Est-ce que la compression GZIP ralentit le serveur?

Au contraire. Oui, le processeur consacre des ressources à la compression, mais il s’agit d’une charge microscopique par rapport au gain obtenu grâce à la réduction des données transmises. Au niveau de compression 6 (le compromis standard), le processeur traite l’opération en quelques millisecondes. Le seul scénario où la compression peut devenir perceptible est celui d’un VPS très faible doté de 512 Mo de mémoire et de milliers de visiteurs simultanés. Mais dans cette situation, vous avez des problèmes plus graves que la compression GZIP. En pratique, la compression ne ralentit pas le serveur: une page WordPress typique est compressée en 2 à 5 millisecondes, tandis que les gains sur la transmission des données via le réseau se chiffrent en dizaines et centaines de millisecondes pour chaque visiteur. La compression est toujours plus bénéfique que son absence.

GZIP ou Brotli: que choisir en 2026?

Commencez par GZIP; cela fonctionne sur n’importe quel hébergement et est pris en charge par tous les navigateurs sans exception. Brotli compresse nettement mieux, mais nécessite le HTTPS (ce qui n’est pas un problème en 2026) et une prise en charge côté serveur. Si l’hébergement ou le CDN (Cloudflare, BunnyCDN) prend en charge Brotli, activez-le en complément de GZIP. La plupart des sites modernes utilisent les deux: le serveur sert du Brotli aux navigateurs qui le comprennent et du GZIP à tous les autres.

La compression GZIP est-elle compatible avec un CDN?

Totalement. Les CDN comme Cloudflare ou BunnyCDN compressent eux-mêmes le contenu sur leurs serveurs edge, souvent en Brotli, même si votre hébergement ne le prend pas en charge. Si le site est déjà derrière Cloudflare, vérifiez que l’option «Brotli» est activée dans «Vitesse» → «Optimisation». Dans ce scénario, configurer GZIP au niveau du serveur reste utile comme solution de repli pour les requêtes directes vers le serveur d’origine.

J’ai une extension de cache. Dois-je activer GZIP séparément?

Cela dépend de l’extension. WP Rocket active GZIP automatiquement, W3 Total Cache le fait via une case à cocher distincte, WP Super Cache également via une case à cocher distincte. Vérifiez les réglages de votre extension; presque toutes les extensions de cache proposent une option de compression, mais toutes ne l’activent pas par défaut. Ne partez pas du principe que «cela devrait fonctionner»; vérifiez via DevTools après la configuration.

Puis-je compresser les pages via le fichier functions.php?

Techniquement, vous le pouvez, via la fonction PHP ob_start('ob_gzhandler'), mais nous ne le recommandons pas. Cette méthode compresse la sortie PHP et n’affecte pas les fichiers statiques (CSS, JS) qui représentent l’essentiel du trafic. La compression côté serveur (Apache/NGINX) fonctionne pour tous les types de fichiers et ne sollicite pas le processeur PHP. Réservez la compression PHP aux rares cas où l’accès aux configurations serveur est physiquement impossible.

Conclusions: quoi activer et quand

La compression GZIP n’est pas une option que l’on active une fois pour toutes, mais une règle d’hygiène de base pour un site WordPress. Si à l’instant même vous ne savez pas si votre serveur compresse les pages, ouvrez DevTools et vérifiez l’en-tête Content-Encoding. Absent? Revenez à la méthode 1 et ajoutez trois lignes au fichier .htaccess.

Matrice de décision rapide:

  • Site sur Apache et que vous n’avez pas peur du FTP → méthode 1 (.htaccess), 5 minutes
  • Site sur NGINX et que vous avez accès aux fichiers de configuration → méthode 2 (nginx.conf), 10 minutes avec vérification de la syntaxe
  • Vous ne touchez par principe à aucun fichier serveur → W3 Total Cache ou WP Super Cache, 2 minutes
  • Vous payez déjà pour WP Rocket → ne faites rien, la compression fonctionne directement
  • Vous ne voulez rien configurer du tout → écrivez au support de votre hébergeur

Vérifiez le résultat avec l’une des trois méthodes ci-dessus et réglez cette question une bonne fois pour toutes. C’est une de ces rares optimisations qui se fait vraiment une seule fois et continue d’économiser de la bande passante et d’accélérer le site des années plus tard, sans mises à jour, sans abonnement et sans reconfiguration.