Brotli

Brotli est un algorithme de compression sans perte utilisé pour réduire le poids des fichiers texte envoyés par un site web. En clair : moins d’octets à transférer pour vos pages HTML, CSS ou JavaScript, donc un chargement plus rapide quand la configuration est propre. Pour une agence web éco-responsable, c’est un levier intéressant, mais pas une baguette magique. Un site obèse restera obèse, même compressé.

Définition de Brotli

Brotli est un format et un algorithme de compression sans perte développé par Google, puis documenté dans la RFC 7932. « Sans perte » veut dire que le navigateur récupère exactement le même contenu après décompression. Le CSS ne change pas. Le JavaScript ne perd pas une ligne. Seule la façon de transporter les données est optimisée.

Techniquement, Brotli combine notamment une variante de LZ77, du codage de Huffman et un dictionnaire statique. Bon, ce n’est pas la partie que vous devez retenir si vous pilotez un projet web. Le point utile, c’est celui-ci : Brotli sait repérer des répétitions et des motifs fréquents dans les fichiers texte pour les envoyer sous une forme plus compacte.

Sur HTTP, Brotli apparaît avec l’encodage br. Le navigateur annonce par exemple qu’il accepte Brotli avec Accept-Encoding: br. Le serveur répond avec Content-Encoding: br si la ressource est bien servie dans ce format.

À quoi sert Brotli sur un site web ?

Brotli sert à réduire la taille transférée des ressources texte : HTML, CSS, JavaScript, SVG, JSON, XML, parfois certaines polices selon le format et le contexte. C’est particulièrement utile sur les sites qui envoient beaucoup de scripts ou de feuilles de style. Et soyons francs, c’est très souvent le cas.

Le bénéfice le plus visible est côté performance web. Une ressource plus légère traverse le réseau plus vite, surtout sur mobile, en 4G moyenne, dans un train, ou derrière un Wi-Fi d’hôtel qui donne envie de tout fermer. Le navigateur reçoit moins de données, commence plus vite à traiter la page et l’expérience paraît moins lourde.

Dans une démarche d’écoconception web, Brotli a sa place parce qu’il réduit les octets transférés. Attention tout de même : réduire le transfert ne suffit pas à rendre une interface sobre. Si vous chargez 1,8 Mo de JavaScript inutile, Brotli va masquer une partie du problème, pas le résoudre.

• Il ne remplace pas la minification.
• Il ne corrige pas des images trop grandes.
• Il ne dispense pas d’une vraie stratégie de cache.
• Il ne justifie pas d’empiler des librairies front sans arbitrage.

Brotli vs gzip : quelles différences ?

La comparaison Brotli vs gzip revient tout le temps, et pour une bonne raison : gzip reste le vieux réflexe de la compression web, tandis que Brotli donne souvent de meilleurs résultats sur les fichiers texte modernes. Mon avis est assez simple : activez Brotli quand l’infrastructure le permet, gardez gzip en fallback, et ne perdez pas trois jours à chercher un niveau de compression parfait pour un gain microscopique.

Le rôle des niveaux de compression

Brotli propose des niveaux de compression de 0 à 11. Plus le niveau monte, plus le fichier peut devenir compact, mais plus le serveur travaille pour le produire. Niveau 11 sur chaque réponse dynamique ? Mauvaise idée dans beaucoup de cas. Le résultat peut être plus petit, oui. Le coût CPU peut aussi devenir absurde.

Pour des fichiers statiques générés au build, comme app.js ou style.css, les niveaux élevés sont plus défendables. On compresse une fois, on sert ensuite le fichier depuis le cache ou le CDN. Pour du contenu généré à la volée, il faut rester raisonnable.

Compression dynamique ou fichiers pré-compressés ?

Deux approches existent. La compression dynamique compresse la réponse au moment où le serveur l’envoie. C’est pratique, mais cela consomme du CPU à chaque demande si le cache ne prend pas le relais. Les fichiers pré-compressés, eux, sont générés en amont, souvent pendant le build front, avec des extensions comme .br.

En pratique, je préfère la pré-compression pour les assets versionnés et cachables. C’est plus propre, plus prévisible, et ça évite de transformer le serveur en moulin à compression.

Comment savoir si Brotli est activé ?

Le test le plus rapide se fait dans les DevTools du navigateur. Ouvrez l’onglet Réseau, rechargez la page, cliquez sur une ressource HTML, CSS ou JS, puis regardez les en-têtes de réponse. Si vous voyez Content-Encoding: br, Brotli est actif pour cette ressource.

1. Ouvrir les DevTools, puis l’onglet Network ou Réseau.
2. Sélectionner une ressource texte : document HTML, CSS, JS, SVG ou JSON.
3. Vérifier Content-Encoding: br dans les Response Headers.
4. Contrôler que Vary: Accept-Encoding est cohérent pour le cache.
5. Tester le fallback gzip si vous devez couvrir des clients plus anciens.

Vous pouvez aussi utiliser curl avec un en-tête Accept-Encoding: br, ou un test de compression en ligne. Petite nuance qui évite de faux diagnostics : l’absence de Brotli ne veut pas dire absence totale de compression. Le serveur peut très bien répondre en gzip.

Quand Brotli est-il pertinent dans une démarche d’écoconception web ?

Brotli est pertinent quand une page transfère beaucoup de texte compressible. C’est le cas des interfaces avec plusieurs bundles JavaScript, des sites éditoriaux avec HTML conséquent, des applications web qui échangent du JSON, ou des front-ends où le CSS a pris trop de poids avec le temps. Oui, ça arrive vite. Trop vite.

Son intérêt est net quand il s’insère dans une chaîne déjà sérieuse : assets minifiés, cache HTTP correct, CDN bien configuré, versioning des fichiers, suppression du code inutilisé. Là, Brotli réduit le transfert sans déplacer le problème ailleurs. C’est exactement le genre de levier discret qui aide la performance et la sobriété numérique, sans promesse carbone hasardeuse.

Le bon réflexe : mesurer le poids transféré avant et après activation. Pas seulement le poids non compressé affiché dans votre build.

Côté Core Web Vitals, Brotli peut aider indirectement. Moins d’octets à télécharger peut améliorer le démarrage du rendu, surtout sur réseau lent. Mais il ne réglera pas un LCP pénalisé par une image hero de 900 ko, ni un INP plombé par trop de JavaScript exécuté côté client. Frustrant, mais vrai.

Les limites à connaître

Brotli est largement supporté par les navigateurs modernes, mais un fallback gzip reste une bonne pratique. Certains contextes anciens, proxys, outils ou clients HTTP peuvent ne pas demander br. Le serveur doit donc négocier proprement selon Accept-Encoding, pas supposer que tout le monde sait lire Brotli.

Autre limite : le coût CPU. Une compression dynamique trop agressive peut ralentir le serveur, surtout sur des pages générées à chaque requête. Dans ce cas, vous économisez des octets mais vous dépensez du calcul. Le bilan n’est pas automatiquement meilleur.

Les formats déjà compressés ne sont pas les bonnes cibles. JPG, PNG, WebP, AVIF, MP4 ou fichiers audio compressés gagnent peu, parfois rien. Les recomprimer fait surtout perdre du temps. Même logique pour WOFF2, déjà compressé avec Brotli dans son format.

Enfin, la configuration compte. Il faut éviter la double compression, vérifier Vary: Accept-Encoding, servir le bon fichier depuis le cache, et ne pas casser les ETag ou la négociation côté CDN. C’est là que les erreurs se glissent. Pas spectaculaire, mais pénible à déboguer.

Brotli en bref

Brotli est un algorithme de compression sans perte pensé pour envoyer des ressources web texte plus légères, via l’encodage HTTP br. Son intérêt principal : réduire le poids transféré et accélérer le chargement, souvent mieux que gzip sur HTML, CSS, JavaScript, SVG ou JSON.

Le point de vigilance tient en une phrase : Brotli doit être configuré avec cache, fallback gzip et mesure réelle. Dans un projet web responsable, il mérite clairement sa place, mais après les gros arbitrages : réduire le JavaScript, optimiser les images, nettoyer le CSS, maîtriser les dépendances et suivre le poids des pages dans le temps.