L'audit PageSpeed recommande Brotli. L'équipe active brotli on; brotli_comp_level 11 sur nginx pour tout — y compris une API JSON de deux cents kilo-octets générée à chaque requête. Le délai jusqu'au premier octet passe de cent vingt millisecondes à trois cent quatre-vingts sur un VPS à deux vCPU ; le score Lighthouse monte sur la métrique « octets transférés ». Les utilisateurs mobiles, eux, ressentent la lenteur.
La compression réduit les octets — elle coûte du processeur et parfois du délai jusqu'au premier octet. Brotli versus gzip n'est pas une religion : c'est un arbitrage sur où et à quel niveau compresser, en fonction du type de contenu et de la charge serveur.
gzip vs Brotli : les compromis
| Algorithme | Compression | Vitesse de compression | Usage typique |
|---|---|---|---|
| gzip niveau 6 | Bon | Rapide | HTML dynamique, API |
| brotli niveau 4 à 6 | Meilleur | Modéré | Dynamique si processeur disponible |
| brotli niveau 11 + précompression | Maximum | Hors ligne | .js/.css statiques |
La précompression consiste à générer file.js.br en amont (brotli -k file.js) puis à le servir avec Content-Encoding: br — zéro charge processeur au moment de la requête.
Compresser une image JPEG, c'est payer du processeur pour zéro octet économisé.
nginx, Apache, CDN : une seule couche
Sur nginx, configurez gzip on; gzip_types ...; brotli on; brotli_types ...; avec des niveaux modérés (quatre à six). Cloudflare et les CDN similaires incluent souvent la compression au bord — désactivez la double compression côté origine.
Sur mutualisé, la compression est parfois imposée par le panneau de contrôle. Mesurez l'impact sur le délai jusqu'au premier octet avant d'empiler plusieurs couches.
Dynamique vs statique : deux stratégies
Pour le statique, le pipeline de build produit des fichiers .gz et .br ; nginx active gzip_static on; brotli_static on;. Pour le dynamique, gzip niveau cinq suffit souvent — mesurez le délai au percentile 95 avant d'activer un Brotli agressif. Pour les API JSON, la compression devient utile au-delà d'un à deux kilo-octets ; les micro-réponses n'en bénéficient pas.
HTTP/2 et HTTP/3 changent la compression des en-têtes, pas la logique du corps compressible.
Mutualisé et VPS : contraintes hébergeur
Sur mutualisé, la compression est souvent activée globalement par l'hébergeur — vous ne choisissez pas toujours l'algorithme ni le niveau. Mesurez avant d'ajouter une couche PHP ou un plugin WordPress qui compresse déjà ce que le serveur compresse. Sur VPS, vous contrôlez nginx ou Apache — mais un VPS deux vCPU saturera vite avec Brotli niveau onze sur HTML dynamique sous charge Black Friday.
Consultez la fiche hébergeur dans l'annuaire pour vérifier si compression edge ou CDN est incluse — parfois le meilleur gain vient du produit hébergeur plutôt d'un réglage nginx agressif.
Mesurer : octets versus latence
Comparez les octets transférés (outils développeur du navigateur), le délai jusqu'au premier octet (Navigation Timing) et la charge processeur de l'origine sous charge réelle. L'objectif est un gain d'octets sans augmenter le délai de plus de cinquante millisecondes sur les pages critiques.
Erreurs fréquentes
Double compression PHP plus nginx. Oubli de gzip_min_length 256. Brotli appliqué aux flux SSE ou WebSocket, où il est inapproprié. Niveau maximal sur HTML généré sous charge, transformant un VPS modeste en goulet processeur.
Le sommet : score Lighthouse, expérience dégradée
Compresser sans ajouter de latence, c'est précompresser le statique, modérer le dynamique, et compresser au bon saut réseau (bord de réseau plutôt qu'origine).
Décider et avancer sans angle mort
Auditez les types MIME servis et éliminez la compression inutile sur les formats déjà compressés. Précompressez les assets statiques en build et servez-les via nginx ou CDN. Appliquez gzip ou Brotli modéré sur le HTML dynamique après mesure. Vérifiez qu'une seule couche compresse chaque réponse. Mesurez le délai jusqu'au premier octet avant et après tout changement. Comparez hébergeurs et CDN via l'annuaire et le comparateur.
Questions fréquentes
Brotli vaut-il toujours mieux que gzip ?
Brotli compresse généralement mieux le texte, surtout aux niveaux élevés — mais il est plus lent à compresser. Il est idéal pour les assets statiques précompressés ; gzip ou Brotli à niveau modéré conviennent mieux au HTML dynamique.
Où compresser — nginx, CDN ou PHP ?
Préférez le bord de réseau ou nginx pour les fichiers statiques. Évitez de compresser dans PHP si nginx le fait déjà. Sur mutualisé, vérifiez les limites processeur imposées par l'hébergeur.
Quels types MIME compresser ?
text/html, text/css, application/javascript, application/json, image/svg+xml — pas les JPEG, PNG ou WebP déjà compressés.
Comment servir Brotli aux navigateurs anciens ?
Négociation via Accept-Encoding : Brotli si supporté, sinon gzip. Le CDN gère souvent les deux versions en cache séparé grâce à l'en-tête Vary.
Moins d'octets ne comptent que si le premier octet arrive à temps.