Compression Brotli en 2026 : Réduire le Poids des Ressources pour Optimiser LCP et TTFB

Activer la compression Brotli sur votre serveur réduit immédiatement le volume transféré pour chaque ressource textuelle — HTML, CSS, JavaScript, JSON — ce qui diminue le Time to First Byte effectif et accélère le rendu du Largest Contentful Paint.

La plupart des serveurs web n'activent que gzip par défaut. Brotli est supporté par tous les navigateurs modernes depuis plusieurs années et offre un meilleur taux de compression à niveau comparable, mais il nécessite une configuration explicite côté serveur. Cet article vous guide à travers les choix techniques et la mise en œuvre pratique.

Compression HTTP et métriques de performance

Le navigateur doit télécharger le HTML, le CSS bloquant et le JavaScript avant de pouvoir afficher quoi que ce soit à l'écran. Chaque octet transféré en moins réduit le temps de transfert réseau, qui constitue l'une des sous-parties du LCP mesurées par le navigateur : la réduction du payload est directement visible dans le resource load duration que Chrome DevTools décompose lors de l'analyse du LCP.

La compression opère au niveau du transport : le serveur envoie une réponse compressée, le navigateur la décompresse en mémoire avant de l'analyser. La décompression Brotli est rapide — comparable à gzip — ce qui signifie que le coût côté client est négligeable par rapport au gain de bande passante pour les ressources de taille significative. Pour les très petits fichiers, la plupart des serveurs appliquent un seuil minimum en dessous duquel la compression n'est pas déclenchée.

Les types MIME qui bénéficient de la compression :

• HTML (text/html)
• CSS (text/css)
• JavaScript (application/javascript, text/javascript)
• JSON (application/json)
• SVG (image/svg+xml)
• Polices non compressées (font/ttf, font/otf) — mais pas font/woff2, déjà compressé
• XML et réponses d'API textuelles

Brotli vs gzip : différences techniques

Gzip repose sur l'algorithme DEFLATE (une combinaison de LZ77 et de codage de Huffman), introduit dans les années 1990 et universellement supporté. Brotli, publié par Google, combine un dictionnaire statique préintégré de termes courants du Web — balises HTML, noms de propriétés CSS, méthodes JavaScript fréquentes — avec LZ77 et un codage entropique amélioré. Ce dictionnaire permet à Brotli de référencer des séquences communes sans les stocker dans le flux compressé, ce qui améliore le taux de compression dès la première requête.

Brotli produit des fichiers plus petits que gzip sur les ressources textuelles typiques d'une page web. Les fichiers JavaScript minifiés et les feuilles de style CSS bénéficient particulièrement de ce dictionnaire statique orienté Web. L'ampleur du gain dépend du contenu et du niveau de compression configuré.

La négociation du format se fait via les en-têtes HTTP standards :

# Requête du navigateur
Accept-Encoding: gzip, deflate, br, zstd

# Réponse du serveur avec Brotli
Content-Encoding: br
Vary: Accept-Encoding

Si le serveur ne peut pas produire de Brotli, il revient à gzip ou deflate selon ce que le client accepte. L'en-tête Vary: Accept-Encoding est indispensable : sans lui, un CDN ou un proxy intermédiaire pourrait mettre en cache la version Brotli et la servir à un client qui ne supporte pas ce format, produisant un contenu illisible.

Niveaux de compression et compromis

Brotli définit des niveaux de compression de 0 à 11, où 0 est le plus rapide (et le moins compressé) et 11 le plus lent (et le plus compressé). Ce spectre plus étendu que celui de gzip (0 à 9) permet une flexibilité accrue selon le contexte d'utilisation.

Pour la compression dynamique (à la volée lors de la requête), le niveau 4 à 6 est le compromis habituellement retenu. Aux niveaux élevés, la durée de compression peut allonger le TTFB de façon perceptible. Pour la compression statique, le niveau 11 est recommandé car le travail est effectué une seule fois lors du build ou du déploiement.

Compression statique vs dynamique

La compression dynamique compresse la réponse à chaque requête (ou dans un cache intermédiaire côté serveur). Elle convient aux réponses générées à la volée : pages HTML personnalisées, réponses JSON d'API. Elle ne nécessite pas de gérer des fichiers supplémentaires sur le disque.

La compression statique consiste à pré-compresser les fichiers lors du build et à les stocker à côté des originaux — par exemple bundle.js.br aux côtés de bundle.js. Le serveur détecte la préférence du navigateur via Accept-Encoding et sert directement le fichier .br sans aucun CPU supplémentaire lors de la requête. C'est l'approche optimale pour les assets statiques (JS, CSS, HTML statique) pour trois raisons :

• Le niveau 11 peut être appliqué sans impact sur la latence
• Aucun CPU n'est consommé pour la compression en production
• Le taux de compression est maximal

Pré-compression lors du build

La plupart des bundlers modernes proposent des plugins capables d'émettre des fichiers .br et .gz en parallèle des fichiers originaux lors du build. La configuration typique demande de spécifier l'algorithme Brotli, le niveau 11 et les extensions à compresser (.js, .css, .html, .svg). Consultez le catalogue de plugins de votre bundler (Vite, Rollup, Webpack) pour trouver l'option correspondante.

Configuration sur les serveurs courants

nginx avec ngx_brotli

nginx ne supporte pas Brotli nativement : il requiert le module tiers ngx_brotli, maintenu par Google. Ce module doit être compilé avec nginx ou installé comme module dynamique selon votre distribution ou image Docker.

brotli on;
brotli_comp_level 6;
brotli_types
    text/html
    text/css
    text/javascript
    application/javascript
    application/json
    image/svg+xml
    font/ttf
    font/otf;

# Sert les fichiers .br pré-compressés si disponibles
brotli_static on;

Avec brotli_static on, nginx recherche un fichier nom.br sur disque avant de compresser à la volée. Si votre pipeline de build génère des fichiers .br, cette directive les utilise directement sans consommer de CPU à la demande.

Apache avec mod_brotli

Le module mod_brotli est disponible dans les versions récentes d'Apache et doit être chargé explicitement.

LoadModule brotli_module modules/mod_brotli.so

<IfModule mod_brotli.c>
    AddOutputFilterByType BROTLI_COMPRESS text/html text/css application/javascript text/javascript application/json image/svg+xml
    BrotliCompressionQuality 6
</IfModule>

Header always set Vary "Accept-Encoding"

Node.js

Node.js expose nativement Brotli via le module zlib. La fonction createBrotliCompress() accepte un objet params où la qualité se règle via la constante constants.BROTLI_PARAM_QUALITY :

import { createBrotliCompress, constants } from 'node:zlib';

const brotli = createBrotliCompress({
  params: {
    [constants.BROTLI_PARAM_QUALITY]: 4
  }
});

// Pipe vers la réponse HTTP
readable.pipe(brotli).pipe(response);

Pour servir des fichiers statiques pré-compressés avec Express, un middleware peut vérifier l'existence d'un fichier .br correspondant et l'envoyer avec l'en-tête Content-Encoding: br si le client annonce br dans Accept-Encoding.

CDN et plateformes d'hébergement

La plupart des CDN et plateformes d'hébergement modernes activent Brotli par défaut ou sur option dans leur interface de configuration. Vérifiez la documentation de votre fournisseur. Sur certains CDN, Brotli est appliqué à l'edge mais la communication avec l'origine reste en gzip : dans ce cas, pré-compresser sur l'origine permet au CDN de mettre en cache les variantes Brotli directement, sans recompression intermédiaire.

Vérifier et diagnostiquer

La vérification la plus directe consiste à inspecter les en-têtes de réponse. Dans Chrome DevTools, ouvrez l'onglet Network, cliquez sur une ressource textuelle et recherchez Content-Encoding: br dans la section Response Headers. La colonne Size affiche deux valeurs : la taille transférée (compressée) et la taille décompressée — un écart important confirme que la compression fonctionne.

En ligne de commande, curl permet de simuler la négociation Brotli :

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

La réponse doit contenir Content-Encoding: br si Brotli est actif pour cette ressource.

Vérifier la présence de Vary

L'absence de Vary: Accept-Encoding peut provoquer des bugs de cache silencieux : un proxy ou un CDN met en cache la version Brotli et la sert à un client qui ne le supporte pas. Vérifiez systématiquement que cet en-tête est présent sur toutes les ressources compressées, y compris les réponses HTML dynamiques.

Mesurer l'impact sur les Core Web Vitals

Après activation, comparez les distributions de LCP dans vos données terrain (RUM) avant et après le déploiement. Le rapport CrUX dans Google Search Console permet d'observer l'évolution du LCP au 75e percentile sur votre origine. Le gain est souvent plus visible sur les connexions mobiles ou dans les régions à bande passante limitée, où la réduction de taille a le plus d'impact sur la durée de chargement.