Le code d’une page web, qu’il s’agisse du balisage, des feuilles de style ou des scripts, est du texte, et le texte se compresse remarquablement bien. Plutôt que d’envoyer ces fichiers tels quels, un serveur peut les compresser avant de les transmettre, et le navigateur les décompresse à la réception. C’est le rôle de la compression HTTP, assurée par deux algorithmes principaux : Gzip et Brotli. Activée d’un simple réglage serveur, elle réduit souvent de plus de deux tiers le poids des fichiers texte, pour un gain de vitesse immédiat et quasi gratuit. Voyons ce que recouvre cette compression, comment elle fonctionne, pourquoi elle accélère vos pages, et comment l’activer concrètement.

La compression HTTP, définition de Gzip et Brotli

La compression HTTP est un mécanisme par lequel le serveur réduit la taille des fichiers texte avant de les envoyer au navigateur, qui les décompresse à l’arrivée. Elle complète d’autres optimisations comme la minification du code, en s’attaquant au poids du transfert lui-même. Assurée par Gzip ou Brotli, elle agit de façon transparente pour l’utilisateur, sans rien changer au contenu reçu.

Le principe de la compression HTTP

Le code source d’une page contient énormément de répétitions : balises, mots-clés, espaces, motifs récurrents. Les algorithmes de compression exploitent ces redondances pour décrire le même contenu avec beaucoup moins de données. Le serveur envoie alors une version compacte du fichier, que le navigateur reconstitue à l’identique avant de l’interpréter. Tout cela se déroule sans la moindre perte. Le fichier décompressé est rigoureusement identique à l’original, contrairement à la compression d’images avec perte. C’est une compression sans perte par nature, ce qui la rend parfaitement sûre pour du code, où la moindre altération provoquerait une erreur. L’opération est si rapide qu’elle est imperceptible pour le visiteur. Le léger temps de décompression côté navigateur est très largement compensé par le temps gagné au téléchargement d’un fichier plus petit. Ce bénéfice net sur le temps total explique que la compression HTTP soit recommandée pour la quasi-totalité des sites.

Gzip et Brotli, deux algorithmes

Gzip est le plus ancien et le plus répandu : éprouvé depuis des décennies, supporté absolument partout, il offre une compression solide pour un coût de calcul modéré. C’est la valeur sûre et universelle, présente par défaut sur la plupart des serveurs et reconnue par tous les navigateurs sans exception. Brotli, plus récent, pousse la compression plus loin et produit des fichiers encore plus légers, en particulier pour le texte. Son efficacité supérieure en fait un choix de prédilection dès lors que le serveur et les navigateurs le supportent, ce qui est aujourd’hui le cas de l’écrasante majorité du parc. Les deux ne s’excluent pas : un serveur bien configuré propose Brotli en priorité et bascule sur Gzip pour les rares cas qui ne le supportent pas. Cette complémentarité garantit à chaque visiteur la meilleure compression disponible, sans jamais laisser quiconque sans compression du tout faute de compatibilité.

Comment fonctionnent Gzip et Brotli

Le fonctionnement de la compression HTTP repose sur un dialogue entre le navigateur et le serveur, et sur un choix de méthode adapté au contenu. En comprendre les rouages aide à diagnostiquer pourquoi la compression est, ou n’est pas, active sur un site. Ce sujet complète notre précédent article : compression d’images WebP et AVIF.

La négociation entre navigateur et serveur

À chaque requête, le navigateur annonce les algorithmes de compression qu’il sait décoder. Le serveur consulte cette liste, choisit la meilleure méthode commune, compresse le fichier en conséquence et signale dans sa réponse le format employé. Cette négociation automatique se fait à chaque échange, sans aucune intervention de l’utilisateur ni du développeur. Ce mécanisme garantit une compatibilité totale. Si un navigateur ne supporte qu’un algorithme ancien, le serveur s’y adapte ; s’il supporte le plus récent, il en profite. Cette adaptation au cas par cas permet de servir la meilleure compression possible à chacun, sans jamais risquer d’envoyer un format qu’un visiteur ne saurait décoder. C’est aussi par cette négociation que l’on diagnostique un problème. En inspectant les en-têtes d’une réponse, on voit si la compression a été appliquée et avec quel algorithme. Cette trace visible dans les échanges est le premier point à vérifier lorsqu’on soupçonne qu’un site ne compresse pas ses fichiers comme il le devrait.

Ce qui se compresse et ce qui ne se compresse pas

La compression HTTP s’applique aux fichiers texte : balisage, feuilles de style, scripts, données structurées. Ce sont eux qui regorgent de redondances et profitent le plus de l’opération. Sur ces contenus, le gain de poids est spectaculaire et systématique, ce qui en fait la cible naturelle de la compression. À l’inverse, les fichiers déjà compressés, comme les images modernes ou les vidéos, ne gagnent rien à être compressés une seconde fois. Tenter de le faire consommerait du calcul pour un résultat nul, voire contre-productif. Mieux vaut donc exclure ces formats déjà optimisés de la compression, pour ne l’appliquer qu’aux contenus qui en tirent un réel bénéfice. Le tableau ci-dessous indique quels contenus profitent de la compression HTTP.

Compression à la volée ou précompression

Un serveur peut compresser les fichiers à chaque requête, à la volée, ou les compresser une fois pour toutes et servir la version prête. La compression à la volée est simple mais consomme un peu de calcul à chaque demande, ce qui reste acceptable pour la plupart des sites au regard du gain obtenu. La précompression, elle, prépare à l’avance les versions compressées et les sert directement, sans recalcul. Elle convient particulièrement aux fichiers qui ne changent pas souvent, comme les scripts et les styles. Cette compression anticipée offre le meilleur des deux mondes : une compression poussée sans coût de calcul répété à chaque visite. Le choix dépend des contraintes du serveur et de la nature des contenus. Un contenu statique gagne à être précompressé au niveau maximal, un contenu dynamique se compresse à la volée à un niveau modéré. Adapter la stratégie au type de fichier permet d’optimiser à la fois le poids servi et la charge du serveur.

Pourquoi activer Gzip ou Brotli accélère vos pages

Activer la compression HTTP compte parmi les optimisations au meilleur rapport effort/résultat, avec un effet direct sur les indicateurs des Core Web Vitals. En réduisant le poids des fichiers texte, elle raccourcit le téléchargement et débloque plus tôt l’affichage, pour un gain quasi immédiat dès l’activation.

Réduire drastiquement le poids transféré

Sur des fichiers texte, la compression divise couramment le poids par trois, voire davantage avec Brotli. Un script ou une feuille de style volumineux se télécharge alors en une fraction du temps. Cette réduction massive de la donnée transférée se ressent directement sur la vitesse de chargement, surtout pour les visiteurs aux connexions modestes. Ce gain s’applique aux ressources qui bloquent le rendu, comme les feuilles de style. Les recevoir compressées, donc plus vite, permet au navigateur de peindre la page plus tôt. La compression agit ainsi indirectement sur le moment du premier affichage, l’un des repères les plus visibles de la performance perçue d’un site. À l’échelle du trafic, l’économie est considérable. Chaque fichier allégé, multiplié par le nombre de visites, représente une masse de données épargnée. Ce bénéfice cumulatif soulage la bande passante du serveur comme celle des visiteurs, avec un effet appréciable sur les coûts d’hébergement des sites très fréquentés.

Un gain quasi universel et peu coûteux

L’atout majeur de la compression HTTP est son universalité. Elle profite à presque tous les sites, sans exception, dès lors qu’ils servent du texte, c’est-à-dire toujours. Peu d’optimisations offrent un bénéfice aussi large pour un effort de configuration aussi réduit, souvent limité à l’activation d’une option. Son coût est par ailleurs négligeable. Le léger surcroît de calcul côté serveur est sans commune mesure avec le temps gagné côté visiteur. Ce déséquilibre favorable entre un petit coût et un grand bénéfice explique que la compression soit considérée comme une optimisation de base, à activer avant même d’envisager des réglages plus pointus. C’est précisément pour cela que les outils d’audit signalent systématiquement son absence. Un site qui ne compresse pas ses fichiers texte laisse sur la table un gain facile et important. Vérifier et activer la compression devrait donc figurer en tête de toute optimisation, tant le retour est immédiat et certain.

Activer Gzip et Brotli sur votre serveur

Activer la compression HTTP relève le plus souvent d’un réglage serveur, plus que d’un développement. La démarche consiste à vérifier l’état actuel, configurer la compression, puis ajuster son niveau selon les contenus.

Vérifier si la compression est active

Avant toute chose, on contrôle si la compression fonctionne déjà, en inspectant les en-têtes des réponses du site. Un en-tête indiquant l’algorithme employé confirme que tout va bien ; son absence révèle une compression inactive. Ce diagnostic rapide évite d’agir à l’aveugle et indique précisément ce qu’il reste à mettre en place. Des outils en ligne et les outils de développement du navigateur facilitent cette vérification, fichier par fichier. On repère ainsi non seulement si la compression est active, mais aussi sur quels contenus elle s’applique. Cette vue détaillée permet de cibler d’éventuels oublis, comme un type de fichier resté non compressé par mégarde. Ce contrôle initial est aussi l’occasion de mesurer le gain potentiel. Comparer le poids compressé et non compressé d’un fichier donne une idée concrète de l’enjeu. Cette estimation chiffrée aide à prioriser l’action et à justifier l’effort, même minime, auprès des parties prenantes du projet.

Configurer le serveur

L’activation se fait au niveau du serveur web ou de la plateforme d’hébergement, en déclarant les types de fichiers à compresser et les algorithmes à utiliser. La plupart des environnements proposent cette option de façon directe. Cette configuration centralisée s’applique alors à l’ensemble du site, sans intervention sur le code lui-même. Il convient de bien lister les types de contenu concernés, pour n’oublier ni les feuilles de style ni les scripts ni les données texte. À l’inverse, on exclut les fichiers déjà compressés. Cette sélection précise des contenus garantit que la compression s’applique partout où elle est utile, et nulle part où elle serait inutile. Sur les hébergements mutualisés ou les plateformes gérées, la compression est fréquemment active par défaut ou activable en un clic. Il suffit alors de vérifier et, au besoin, de cocher une case. Cette simplicité d’activation rend l’optimisation accessible même sans compétence serveur poussée, ce qui la met à la portée de presque tous les sites.

Régler le niveau et maintenir

Les algorithmes proposent plusieurs niveaux de compression, du plus rapide au plus poussé. Un niveau élevé réduit davantage le poids mais demande plus de calcul, ce qui pousse à le réserver aux contenus précompressés. Ajuster ce niveau selon le type de fichier optimise l’équilibre entre poids servi et charge du serveur. Une fois en place, la compression demande peu d’entretien, mais mérite une vérification après chaque évolution majeure de l’infrastructure. Un changement de serveur ou de configuration peut la désactiver à l’insu de l’équipe. Inclure ce contrôle dans les vérifications de routine évite de perdre silencieusement un gain acquis. Le tableau ci-dessous résume une mise en place maîtrisée de la compression HTTP.