Brotli et Gzip réduisent le texte qui voyage : HTML, CSS, JavaScript, JSON, SVG. Ils ne rendent pas une image légère. Le bon réglage est une négociation : Brotli quand le navigateur l’annonce, Gzip sinon, et aucun des deux sur les formats déjà compressés.
Voir ce que le serveur envoie vraiment
Le navigateur envoie Accept-Encoding: br, gzip. Le serveur choisit un codage et le dit dans Content-Encoding.
curl -sI -H "Accept-Encoding: br, gzip, deflate" https://exemple.fr
Puis la même commande avec seulement gzip, pour vérifier le repli. Vous devez voir Content-Encoding: br dans le premier cas, gzip dans le second, et Vary: Accept-Encoding dans les deux. Sans Vary, un cache peut resservir du Brotli à un client qui ne sait pas le lire.
| Gzip | Brotli | |
|---|---|---|
| En-tête | Content-Encoding: gzip | Content-Encoding: br |
| Quand l’utiliser | Repli, et clients anciens | Dès que br est dans Accept-Encoding |
| Niveau utile | 5 ou 6 pour du contenu dynamique | 4 ou 5 à la volée ; 11 seulement pour des fichiers précompressés |
| Ce qui y gagne | HTML, CSS, JS, JSON, SVG | Les mêmes, souvent un peu plus petits, surtout en statique précompressé |
Un niveau Brotli très élevé (11) sur chaque requête PHP charge le processeur pour un gain faible sur du HTML déjà court. Précompressez les fichiers statiques (.br à côté du .js) et laissez un niveau modéré pour les pages générées.
Ce qu’il ne faut pas compresser
Excluez par type : images, vidéo, audio, PDF, archives zip, et font/woff2. La police WOFF2 est déjà en Brotli. La passer une seconde fois dans Gzip ne l’allège pas.
Attention aux doubles couches. Un plugin WordPress qui gzippe le HTML, plus Nginx qui gzippe encore, produit parfois une réponse illisible ou un Content-Encoding menteur. Une seule couche doit compresser. Désactivez celle du plugin si le serveur web le fait déjà, puis retestez avec curl.
Les pages du tunnel de commande et les réponses d’API personnalisées (JSON) se compressent aussi, pas seulement l’accueil. Une fiche produit lourde en HTML et en scripts y gagne avant même de toucher aux images : fiche produit lente.
Lien avec le rendu et le nombre de requêtes
La compression raccourcit les octets d’une ressource. Elle ne réduit pas le nombre de fichiers. Trente petits JavaScript compressés restent trente allers-retours. Ce chantier est dans trop de requêtes HTTP.
Elle ne retire pas non plus un CSS qui bloque le premier affichage. Un fichier plus petit se télécharge plus vite, mais le navigateur attend toujours la fin de ce CSS pour peindre. Le traitement est dans CSS bloquant le rendu.
Sur une page au DOM énorme, le HTML compressé arrive plus vite et le navigateur doit quand même construire tous les nœuds. La compression ne corrige pas ce coût : DOM trop volumineux.
Contrôle après mise en ligne
Content-Encoding: brquand le client acceptebr.Content-Encoding: gzipquand il n’accepte quegzip.- Pas d’en-tête de compression sur une image WebP ou une police WOFF2.
Vary: Accept-Encodingprésent.- La page s’affiche. Une compression cassée se voit par un téléchargement vide ou un HTML illisible, pas par un score.
Gardez Gzip même si tous vos navigateurs cibles parlent Brotli. Les robots, certains proxys d’entreprise et de vieux webviews n’envoient pas br. Le repli est la raison pour laquelle on ne « choisit » pas l’un en supprimant l’autre.
Comparez aussi la taille transférée et la taille décompressée dans l’onglet Réseau. Si les deux tailles sont presque identiques alors que Content-Encoding: br est présent, le corps n’a pas vraiment été réduit (fichier déjà petit, ou en-tête menteur). Retestez une page HTML, pas une image.