Activer la compression Gzip et Brotli sur WordPress

by | WordPress

Si vous avez déjà vu “Enable text compression” dans PageSpeed Insights alors que votre site “semble rapide”, vous êtes probablement en train de servir du HTML/CSS/JS… non compressé. Et sur mobile, ça se traduit vite par un LCP qui dérape et un TTFB qui n’a aucune chance.

Le problème de performance

Quand la compression HTTP (Gzip ou Brotli) n’est pas activée, chaque page HTML, chaque feuille CSS et chaque fichier JS part “en brut” sur le réseau. Sur une page WordPress 6.9.4 typique (thème + plugins + page builder), ça peut représenter plusieurs centaines de kilo-octets inutiles à chaque visite.

Le symptôme le plus visible : un temps de chargement correct sur fibre, mais catastrophique en 4G/3G. Vous le voyez dans les outils : transfert réseau élevé, “Content-Encoding” absent, et un score Core Web Vitals qui baisse surtout sur mobile.

Impact concret :

  • SEO : Google tient compte de la vitesse et des signaux CWV (LCP/INP/CLS) dans l’expérience de page.
  • Taux de rebond : plus la page “met du temps à devenir utilisable”, plus les visiteurs quittent.
  • Coût serveur : sans compression, vous consommez plus de bande passante (et parfois plus de CPU côté CDN/proxy).

À la fin, vous saurez :

  • activer Brotli si votre stack le permet, sinon Gzip proprement via .htaccess (Apache/LiteSpeed),
  • vérifier par code/CLI que la compression est réellement servie,
  • éviter les pièges classiques (double compression, mauvais types MIME, cache qui masque les changements),
  • mettre une solution de repli côté PHP quand l’hébergeur verrouille la config serveur (avec les limites que ça implique).

Résumé rapide

  • Brotli est généralement plus efficace que Gzip, mais dépend du serveur (souvent Nginx/Cloudflare/Apache via module).
  • Sur Apache/LiteSpeed, Gzip s’active proprement via mod_deflate dans .htaccess.
  • La “compression via wp-config.php” existe (zlib), mais c’est un plan B : moins contrôlable, parfois incompatible avec certains caches/proxies.
  • Mesurez avant/après avec une requête HTTP qui affiche Content-Encoding et la taille transférée.
  • Après modification, purgez les caches (plugin cache, cache serveur, CDN, navigateur) sinon vous testez une ancienne réponse.

Diagnostic avec du code

Prérequis : faites une sauvegarde (fichiers + base) avant de modifier .htaccess ou wp-config.php. Ne modifiez jamais le cœur WordPress. Travaillez si possible sur un environnement de staging.

1) Comprendre ce qu’on mesure

La compression HTTP se vérifie via l’en-tête de réponse Content-Encoding :

  • br = Brotli
  • gzip = Gzip
  • absent = pas de compression (ou compression gérée ailleurs mais non annoncée, ce qui est rare et problématique)

Le navigateur envoie l’en-tête Accept-Encoding (ex: br, gzip). Le serveur choisit ce qu’il supporte.

2) Vérifier depuis votre machine (cURL)

Le test le plus fiable, je le fais en terminal. Il évite les extensions navigateur et les caches “invisibles”.

# Remplacez par votre URL (idéalement une page publique non protégée)
URL="https://example.com/"

# Affiche uniquement les en-têtes et force une demande Brotli + Gzip
curl -I -H "Accept-Encoding: br,gzip" "$URL"

# Variante : afficher aussi la taille téléchargée et le type d'encodage reçu
curl -s -o /dev/null 
  -H "Accept-Encoding: br,gzip" 
  -w "http_code=%{http_code}ncontent_type=%{content_type}nsize_download=%{size_download}nsize_header=%{size_header}n" 
  "$URL"

Ce que vous cherchez dans la sortie curl -I :

  • Content-Encoding: br (ou gzip)
  • Vary: Accept-Encoding (important pour que les caches stockent correctement les variantes compressées)

3) Instrumenter WordPress (mesure “temps serveur”)

La compression réduit surtout le poids réseau. Mais je mesure aussi le temps de génération WordPress pour éviter de “célébrer” une compression activée alors que le back-end reste lent.

Collez ce code dans un mu-plugin (recommandé) : créez wp-content/mu-plugins/perf-timing.php. Un mu-plugin (must-use) est chargé automatiquement, sans dépendre du thème.

<?php
/**
 * Plugin Name: Perf Timing (MU)
 * Description: Ajoute des en-têtes de debug pour mesurer le temps serveur. À désactiver en production si inutile.
 * Author: Vous
 */

if (!defined('ABSPATH')) {
	exit;
}

add_action('send_headers', function () {
	// Mesure simple : temps depuis le début de l'exécution PHP (WordPress définit généralement $_SERVER['REQUEST_TIME_FLOAT'])
	$start = isset($_SERVER['REQUEST_TIME_FLOAT']) ? (float) $_SERVER['REQUEST_TIME_FLOAT'] : microtime(true);
	$elapsed_ms = (microtime(true) - $start) * 1000;

	// Attention : n'exposez pas trop d'infos sur un site sensible. Ici on reste minimal.
	header('X-WP-Elapsed-MS: ' . number_format($elapsed_ms, 2, '.', ''));

	// Indique si WordPress pense servir une page en mode "is_admin" (utile pour éviter de tester /wp-admin/)
	header('X-WP-Is-Admin: ' . (is_admin() ? '1' : '0'));
}, 9999);

Test :

curl -I -H "Accept-Encoding: br,gzip" "https://example.com/" | grep -i "x-wp-elapsed|content-encoding|vary"

4) WP_DEBUG et logs (détecter le “lent caché”)

Si votre site a des lenteurs irrégulières, j’ai souvent vu des warnings PHP ou des appels externes bloquants. Activez le log (pas l’affichage) dans wp-config.php :

/** Sauvegardez avant modification. À placer au-dessus de "That's all, stop editing!" */

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);      // Log dans wp-content/debug.log
define('WP_DEBUG_DISPLAY', false); // Ne pas afficher aux visiteurs
@ini_set('display_errors', '0');

Ensuite, surveillez wp-content/debug.log pendant vos tests de compression. Si vous voyez des erreurs, corrigez-les : la compression ne compensera jamais un back-end qui rame.

5) Query Monitor et slow query log (quand le TTFB reste haut)

Query Monitor est le plugin que j’installe en premier sur un site lent. Il affiche les requêtes SQL, hooks, scripts, appels HTTP, etc. Source : Query Monitor sur WordPress.org.

Pour aller plus loin côté base, activez le slow query log MySQL/MariaDB au niveau serveur (si vous avez accès). Comme ce guide est orienté “code”, je ne détaille pas la conf MySQL ici, mais gardez-le en tête si votre TTFB reste élevé après compression.

6) WP-CLI : vérifier l’environnement

WP-CLI vous aide à vérifier versions et extensions actives. Sur un hébergement qui le permet :

# Version WordPress (vous êtes sur 6.9.4)
wp core version

# Version PHP vue par WordPress
wp eval 'echo PHP_VERSION . PHP_EOL;'

# Lister les plugins actifs (un cache ou un plugin sécurité peut interférer)
wp plugin list --status=active

Étape 1 : Activer la compression côté serveur (Gzip/Brotli)

Le principe : compresser les réponses texte (HTML, CSS, JS, JSON, XML, SVG) avant envoi. Les images (JPEG/PNG/WebP/AVIF) sont déjà compressées : les inclure dans Gzip est souvent inutile et parfois contre-productif.

Avant (lent) : aucun encodage, transferts lourds

Exemple de test “avant” :

curl -I -H "Accept-Encoding: br,gzip" "https://example.com/"

Sortie typique :

HTTP/2 200
content-type: text/html; charset=UTF-8
# Pas de Content-Encoding
# Parfois pas de Vary: Accept-Encoding non plus

Après (optimisé) : Gzip via Apache/LiteSpeed (.htaccess)

Où coller le code : dans .htaccess à la racine WordPress (même niveau que wp-config.php), au-dessus du bloc WordPress (# BEGIN WordPress / # END WordPress), ou juste en dessous si votre hébergeur réécrit le fichier. Sur LiteSpeed (très fréquent en mutualisé), ces directives fonctionnent aussi.

Ajoutez ceci :

# === Compression Gzip (Apache/LiteSpeed via mod_deflate) ===
<IfModule mod_deflate.c>
	# Compresser les contenus texte
	AddOutputFilterByType DEFLATE text/plain
	AddOutputFilterByType DEFLATE text/html
	AddOutputFilterByType DEFLATE text/xml
	AddOutputFilterByType DEFLATE text/css
	AddOutputFilterByType DEFLATE text/javascript
	AddOutputFilterByType DEFLATE application/javascript
	AddOutputFilterByType DEFLATE application/x-javascript
	AddOutputFilterByType DEFLATE application/json
	AddOutputFilterByType DEFLATE application/xml
	AddOutputFilterByType DEFLATE application/rss+xml
	AddOutputFilterByType DEFLATE application/atom+xml
	AddOutputFilterByType DEFLATE image/svg+xml
	AddOutputFilterByType DEFLATE font/ttf
	AddOutputFilterByType DEFLATE font/otf
	AddOutputFilterByType DEFLATE application/font-woff
	AddOutputFilterByType DEFLATE application/font-woff2

	# Éviter quelques bugs d'anciens proxies/navigateurs (rare en 2026, mais sans risque)
	BrowserMatch ^Mozilla/4 gzip-only-text/html
	BrowserMatch ^Mozilla/4.0[678] no-gzip
	BrowserMatch bMSIE !no-gzip !gzip-only-text/html

	# Très important : caches/CDN doivent varier selon Accept-Encoding
	<IfModule mod_headers.c>
		Header append Vary Accept-Encoding
	</IfModule>
</IfModule>

Mesure “après” :

curl -I -H "Accept-Encoding: br,gzip" "https://example.com/" | grep -i "content-encoding|vary"

Attendu :

Content-Encoding: gzip
Vary: Accept-Encoding

Brotli : ce que vous pouvez (et ne pouvez pas) faire via .htaccess

Brotli n’est pas “universel” sur Apache en mutualisé. Techniquement, Apache peut le gérer via mod_brotli, mais beaucoup d’hébergeurs ne l’activent pas. LiteSpeed peut aussi servir Brotli, et Cloudflare le fait très bien côté edge.

Dans la pratique (2026), j’obtiens Brotli le plus souvent via :

  • CDN (Cloudflare, Fastly, etc.) : Brotli activé côté edge.
  • Nginx : configuration serveur (pas via .htaccess).
  • LiteSpeed Enterprise : option serveur/host.

Donc : via .htaccess, visez un Gzip propre. Pour Brotli, passez par la section “Configuration serveur” plus bas (Nginx/CDN) ou demandez à l’hébergeur.

Étape 2 : Éviter la compression double et les mauvais types MIME

Une compression “activée” peut empirer les choses si elle est appliquée deux fois (ou appliquée à des contenus déjà compressés). J’ai souvent vu ce cas sur des stacks : plugin cache + reverse proxy + règles .htaccess copiées d’un vieux tuto.

1) Ne compressez pas les images et archives

Si vous forcez la compression sur image/jpeg, image/png, image/webp, image/avif, .zip, .mp4, vous gagnez peu et vous consommez du CPU. Le code de l’étape 1 évite déjà ce piège en ciblant des types texte.

2) Vérifier les types MIME (sinon pas de compression)

Si votre serveur envoie un JS avec Content-Type: text/plain ou un SVG avec un type incorrect, il peut passer à côté des règles. Vérifiez un fichier CSS/JS :

curl -I -H "Accept-Encoding: br,gzip" "https://example.com/wp-content/themes/votre-theme/style.css"

Vous devez voir :

  • Content-Type: text/css
  • Content-Encoding: gzip (ou br)

3) Détecter une double compression

Symptômes :

  • fichiers CSS/JS “corrompus” dans le navigateur,
  • erreurs “Content decoding failed”,
  • réponses avec Content-Encoding: gzip mais un proxy en amont re-compresse.

Test utile : récupérer le corps et tenter une décompression (approche simple) :

# Télécharge et affiche les en-têtes + quelques octets
curl -s -D - -H "Accept-Encoding: gzip" "https://example.com/" | head -n 40

Si vous suspectez une double compression, désactivez temporairement :

  • la minification/compression du plugin cache,
  • la compression au niveau CDN/proxy,
  • ou vos règles .htaccess,

… puis réactivez un seul niveau à la fois.

Étape 3 : Compression côté PHP (quand vous n’avez pas la main sur le serveur)

Vous verrez souvent “activez Gzip dans wp-config.php”. Oui, ça existe via zlib, mais c’est une solution de secours.

Pourquoi je la considère comme un plan B :

  • vous compressez au niveau PHP, pas au niveau serveur : si vous avez un cache page en amont (Varnish, Nginx fastcgi_cache, CDN), le comportement peut devenir confus,
  • vous maîtrisez moins finement les types MIME,
  • en cas de mauvaise config, vous pouvez déclencher des erreurs d’en-têtes (“headers already sent”).

Option A : zlib.output_compression dans wp-config.php

Où coller : dans wp-config.php, avant la ligne “That’s all, stop editing!”.

<?php
// ... wp-config.php

/** 
 * Compression de sortie PHP (plan B).
 * À éviter si votre serveur/CDN compresse déjà, ou si vous utilisez un cache agressif.
 */
@ini_set('zlib.output_compression', 'On');
@ini_set('zlib.output_compression_level', '6'); // 1-9, 6 est un bon compromis CPU/ratio

Mesure :

curl -I -H "Accept-Encoding: gzip" "https://example.com/" | grep -i "content-encoding"

Option B : forcer la compression via un hook WordPress (encore plus “plan B”)

Un hook est un point d’extension de WordPress. Une action est un hook qui exécute du code à un moment donné (contrairement à un filtre qui modifie une valeur).

Si vous ne pouvez pas toucher à wp-config.php mais pouvez ajouter un mu-plugin, vous pouvez activer le buffering gzip. Attention : si un plugin a déjà démarré la sortie, vous aurez “headers already sent”.

Créez wp-content/mu-plugins/gzip-fallback.php :

<?php
/**
 * Plugin Name: Gzip Fallback (MU)
 * Description: Active un buffering gzip côté PHP en dernier recours. À utiliser seulement si la compression serveur est impossible.
 */

if (!defined('ABSPATH')) {
	exit;
}

add_action('init', function () {
	// Ne rien faire si zlib n'est pas dispo
	if (!function_exists('ob_gzhandler')) {
		return;
	}

	// Éviter la double compression si un encodage est déjà prévu
	if (headers_sent()) {
		// Trop tard pour modifier les en-têtes proprement
		return;
	}

	// Si le serveur a déjà décidé d'un encodage, on n'intervient pas
	foreach (headers_list() as $h) {
		if (stripos($h, 'Content-Encoding:') === 0) {
			return;
		}
	}

	// Démarrer le buffer gzip
	ob_start('ob_gzhandler');
}, 1);

Je le répète : ce code est utile quand vous êtes bloqué, mais le meilleur résultat vient d’une compression au niveau serveur/CDN.

Configuration serveur

Cette section est volontairement “copier-coller”. Elle dépend de votre stack. Si vous êtes sur Divi 5, Elementor ou Avada : ça ne change rien, la compression est au niveau HTTP, pas au niveau du builder.

Apache/LiteSpeed : .htaccess (Gzip + en-têtes)

Vous avez déjà le bloc principal à l’étape 1. Voici une variante plus stricte qui ajoute aussi des règles pour éviter des proxys qui retirent Vary :

# === Gzip + Vary (Apache/LiteSpeed) ===
<IfModule mod_deflate.c>
	AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css
	AddOutputFilterByType DEFLATE text/javascript application/javascript application/json
	AddOutputFilterByType DEFLATE image/svg+xml
</IfModule>

<IfModule mod_headers.c>
	# Vary est crucial pour CDN/cache navigateur
	Header merge Vary Accept-Encoding
</IfModule>

Nginx : Brotli/Gzip (exemple de configuration)

Nginx ne lit pas .htaccess. Il faut une configuration serveur. Si vous êtes en VPS, voici un exemple (à adapter). Si vous êtes en mutualisé, demandez à l’hébergeur.

# /etc/nginx/conf.d/compression.conf (exemple)
gzip on;
gzip_comp_level 6;
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;

# Brotli (nécessite module brotli)
brotli on;
brotli_comp_level 5;
brotli_types
  text/plain
  text/css
  text/xml
  application/json
  application/javascript
  application/xml
  application/rss+xml
  image/svg+xml;

CDN (ex: Cloudflare) : Brotli côté edge

Quand un CDN sert Brotli, votre origin (serveur WordPress) peut rester en Gzip, et le CDN optimisera la livraison. C’est souvent le meilleur combo : compression + cache edge.

Point d’attention : si vous mettez un plugin de cache + un CDN, vérifiez que Vary: Accept-Encoding est bien présent, sinon vous pouvez servir une version compressée à un client qui ne l’accepte pas (rare en 2026, mais ça arrive sur certains bots/outils).

PHP.ini / .user.ini : activer zlib (si autorisé)

Sur certains hébergements, vous pouvez activer zlib via un fichier .user.ini (PHP-FPM) :

; .user.ini (exemple)
zlib.output_compression = On
zlib.output_compression_level = 6

Si vous faites ça, évitez de le faire aussi dans wp-config.php (double activation = comportements bizarres).

Vérification des résultats

Ne vous fiez pas à “j’ai collé le snippet”. Vérifiez la réalité HTTP, et faites une mesure avant/après.

1) Vérifier Content-Encoding sur HTML, CSS, JS

BASE="https://example.com"

# HTML
curl -I -H "Accept-Encoding: br,gzip" "$BASE/" | grep -i "content-encoding|vary|content-type"

# CSS (adaptez l'URL)
curl -I -H "Accept-Encoding: br,gzip" "$BASE/wp-includes/css/dist/block-library/style.min.css" | grep -i "content-encoding|content-type"

# JS (adaptez l'URL)
curl -I -H "Accept-Encoding: br,gzip" "$BASE/wp-includes/js/jquery/jquery.min.js" | grep -i "content-encoding|content-type"

2) Mesurer le gain (taille transférée)

Ce test compare la taille téléchargée avec et sans encodage accepté. Ce n’est pas parfait (HTTP/2/3, caches), mais ça donne un ordre de grandeur.

URL="https://example.com/"

echo "== Sans compression demandée =="
curl -s -o /dev/null -H "Accept-Encoding: identity" 
  -w "size_download=%{size_download}n" "$URL"

echo "== Avec br,gzip =="
curl -s -o /dev/null -H "Accept-Encoding: br,gzip" 
  -w "size_download=%{size_download}n" "$URL"

3) Attentes réalistes (ce que vous devriez voir)

  • HTML/CSS/JS : souvent -60% à -85% de taille transférée.
  • TTFB : parfois un peu meilleur, parfois identique (la compression n’accélère pas la génération PHP).
  • LCP mobile : souvent mieux, car moins de données à transférer avant rendu.

4) Purger les caches (sinon vous testez une ancienne version)

Après modification :

  • purgez le cache de votre plugin (si vous en avez un),
  • purgez le cache serveur (LiteSpeed Cache, Nginx cache, Varnish),
  • purgez le cache CDN,
  • faites un test en navigation privée ou avec curl (qui ignore votre cache navigateur).

Si les performances ne s’améliorent pas

Si vous voyez bien Content-Encoding: gzip (ou br) mais que PageSpeed reste mauvais, le problème est ailleurs. J’ai souvent vu ces cas :

1) Le poids principal vient des images ou des polices

La compression texte ne touche pas vos JPEG/WebP/AVIF. Si votre page embarque 6 Mo d’images, Gzip ne changera rien. Vérifiez rapidement :

# Liste les 30 ressources les plus lourdes (nécessite un outil type lighthouse/har + parsing)
# Ici, approche simple : récupérez la page et cherchez les images (indicatif seulement)
curl -s "https://example.com/" | grep -Eo 'src="[^"]+.(jpg|jpeg|png|webp|avif)[^"]*"' | head -n 30

2) TTFB élevé : PHP lent, DB lente, appels externes

Compression ou pas, si votre page met 1,5s à être générée, vous avez un souci back-end.

  • Installez Query Monitor et cherchez les requêtes lentes.
  • Regardez debug.log : warnings/récursions/appels HTTP.
  • Si vous avez un APM (New Relic, Datadog), utilisez-le.

3) Votre cache masque la réalité

Cas fréquent : vous modifiez .htaccess, mais un reverse proxy sert une ancienne réponse sans compression. Testez en ajoutant un paramètre “cache buster” :

curl -I -H "Accept-Encoding: br,gzip" "https://example.com/?nocache=$(date +%s)" | grep -i "content-encoding|age|x-cache|cf-cache-status"

4) Hébergement “verrouillé”

Certains mutualisés désactivent mod_deflate. Dans ce cas :

  • demandez l’activation à l’hébergeur,
  • passez par un CDN qui compresse (Brotli),
  • ou utilisez la solution PHP (avec prudence) de l’étape 3.

Pièges et erreurs courantes

Voici les erreurs que je rencontre le plus souvent lors d’une mise en place Gzip/Brotli sur WordPress (toutes versions récentes, y compris 6.9.4).

Symptôme Cause probable Vérification Solution
Pas de Content-Encoding après ajout du snippet Serveur Nginx (ignore .htaccess) ou mod_deflate désactivé curl -I + demandez la stack à l’hébergeur Configurer Nginx, activer mod_deflate, ou utiliser CDN/Brotli
Erreur 500 après modification de .htaccess Directive non supportée / bloc mal fermé Logs Apache/LiteSpeed, test en retirant le dernier bloc Restaurer le fichier, ré-ajouter progressivement, vérifier <IfModule>
CSS/JS “cassé”, erreur de décodage Double compression (CDN + PHP + .htaccess) Comparer en-têtes côté origin vs CDN, chercher Content-Encoding Ne garder qu’un niveau de compression, purger tous les caches
Vous testez, rien ne change Cache navigateur/CDN sert une ancienne réponse Tester avec curl + paramètre ?nocache= Purger cache plugin/serveur/CDN, retester
“headers already sent” après ajout dans wp-config.php Espaces/UTF-8 BOM avant <?php ou sortie prématurée d’un plugin Logs PHP, vérifier le début du fichier Supprimer espaces/BOM, éviter compression PHP, préférer serveur
Compression OK sur HTML mais pas sur CSS/JS Types MIME incorrects ou fichiers servis par un autre vhost/CDN curl -I sur l’URL exacte du fichier Corriger MIME côté serveur, vérifier règles CDN, étendre AddOutputFilterByType
Vous avez collé le code au mauvais endroit Snippet placé dans functions.php au lieu de .htaccess Relecture : mod_deflate n’a rien à faire en PHP Mettre les directives dans .htaccess ou conf serveur

Deux notes “bêtes” mais réelles

  • Oublier un point-virgule dans wp-config.php casse le site. Faites une sauvegarde et utilisez un éditeur qui colore la syntaxe.
  • Tester sur production sans filet : j’ai déjà vu un .htaccess invalide mettre un site hors-ligne. Faites au minimum une copie du fichier et gardez un accès FTP/SSH.

Conseils de maintenance

  • Gardez un test cURL dans vos notes (ou un script) et lancez-le après chaque changement d’hébergement, de CDN, ou de plugin cache.
  • Surveillez vos en-têtes : un changement de proxy peut supprimer Vary ou forcer un encodage.
  • Évitez les “snippets magiques” trouvés sur des vieux articles : beaucoup datent d’avant HTTP/2 généralisé et ajoutent des directives inutiles ou risquées.
  • Si vous utilisez Divi 5 / Elementor / Avada : la compression ne dépend pas du builder. Par contre, ces outils ajoutent souvent beaucoup de JS/CSS : la compression aide, mais pensez aussi à désactiver les modules inutiles et à optimiser le chargement (defer/async) dans un autre chantier.
  • Après mise à jour majeure (WordPress, cache, CDN), refaites un contrôle : Content-Encoding, Vary, et un test mobile.

Ressources

FAQ

Gzip ou Brotli : lequel choisir en 2026 ?

Si vous pouvez activer Brotli au niveau CDN/serveur, choisissez Brotli. Sinon, Gzip via .htaccess reste une optimisation solide et largement compatible.

Est-ce que WordPress 6.9.4 a un réglage natif pour Gzip ?

Non. WordPress ne “pilote” pas la compression HTTP côté serveur. Il peut au mieux proposer des solutions PHP, mais la voie normale est la configuration serveur/CDN.

Pourquoi mon hébergeur dit “Gzip activé” mais je ne vois rien ?

Parce que vous testez une ressource différente (ex: page HTML compressée, mais fichiers CSS servis par un sous-domaine/CDN sans compression), ou parce qu’un cache sert une ancienne réponse. Testez plusieurs URLs (HTML + CSS + JS) avec curl -I.

Dois-je activer la compression pour les polices (woff2) ?

En général non. woff2 est déjà compressé. Vous pouvez le laisser dans la liste sans trop de dégâts, mais le gain est faible. Si vous cherchez l’optimisation fine, concentrez-vous sur HTML/CSS/JS/JSON/SVG.

Activer zlib dans wp-config.php est-il “dangereux” ?

Ça peut l’être si vous avez déjà une compression en amont (CDN/proxy) ou si des sorties démarrent trop tôt (erreurs d’en-têtes). Utilisez-le seulement si vous ne pouvez pas configurer le serveur.

J’ai collé le code .htaccess dans functions.php et mon site ne va pas plus vite

C’est normal : functions.php est exécuté par PHP, alors que .htaccess configure Apache/LiteSpeed. Les directives <IfModule mod_deflate.c> n’ont aucun effet en PHP. Remettez-les dans .htaccess.

Pourquoi faut-il “Vary: Accept-Encoding” ?

Parce qu’un cache (CDN, proxy, cache navigateur) doit stocker des variantes selon l’encodage accepté. Sans Vary, un cache peut servir une version gzip à un client qui ne l’accepte pas, ou l’inverse.

La compression améliore-t-elle le TTFB ?

Parfois un peu, mais ce n’est pas sa cible principale. Elle réduit surtout le temps de transfert et accélère l’affichage. Si votre TTFB est haut, cherchez plutôt côté PHP/DB/cache objet/cache page.

Elementor/Divi/Avada changent-ils quelque chose à la compression ?

Non. Ils augmentent souvent la quantité de CSS/JS, donc la compression devient encore plus rentable, mais l’activation reste au niveau serveur/CDN.

Je suis en HTTP/3 (QUIC). La compression marche pareil ?

Oui. Brotli/Gzip restent des encodages de contenu HTTP. Le transport (HTTP/2/3) ne remplace pas la compression du corps des réponses.

Comment être sûr que je reçois Brotli et pas Gzip ?

Forcez Accept-Encoding: br et vérifiez Content-Encoding: br :

curl -I -H "Accept-Encoding: br" "https://example.com/" | grep -i "content-encoding"

Articles connexes

Submit a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.