Avant même de penser à optimiser des images ou réduire le nombre de scripts, un réglage serveur simple réduit déjà sensiblement le poids transféré sur chaque page : la compression des fichiers texte. Deux algorithmes dominent ce terrain, Gzip et Brotli, et comprendre leur différence aide à vérifier que votre hébergement en profite correctement.
Comment fonctionne la compression côté serveur
Quand un navigateur demande une page, il indique dans l'en-tête Accept-Encoding quels algorithmes de compression il accepte. Si le serveur est configuré pour compresser, il renvoie le fichier compressé avec un en-tête Content-Encoding correspondant, et le navigateur le décompresse de son côté avant de l'afficher. Cette compression s'applique aux contenus textuels : HTML, CSS, JavaScript, JSON, fichiers SVG. Elle n'a en revanche aucun intérêt sur des formats déjà compressés comme le JPEG, le PNG ou les vidéos, où elle peut même ajouter un coût de traitement inutile sans gain de poids.
Gzip, la référence historique
Gzip est pris en charge par la quasi-totalité des serveurs et navigateurs depuis des années, ce qui en fait l'algorithme de compression le plus universel. Sur Apache, il s'active via le module mod_deflate ; sur Nginx, via la directive gzip on. Sa fiabilité et sa large compatibilité en font un choix par défaut solide, même s'il n'est plus l'algorithme le plus performant disponible aujourd'hui.
Brotli, une alternative plus récente
Développé par Google, Brotli utilise un dictionnaire de compression plus riche, pensé spécifiquement pour le contenu web (HTML, CSS, JS), ce qui lui permet généralement de produire des fichiers plus légers que Gzip pour un même contenu texte, à qualité de compression équivalente. Il est aujourd'hui pris en charge par tous les navigateurs modernes. Sur Nginx, il nécessite le module ngx_brotli (souvent déjà intégré sur les hébergements modernes) ; sur Apache, le module mod_brotli. La bonne pratique consiste à activer Brotli en priorité quand le navigateur le supporte, avec Gzip comme solution de repli pour les clients plus anciens.
Comment vérifier que votre site est bien compressé
Depuis les outils de développement du navigateur, l'onglet réseau affiche la taille transférée et la taille réelle du fichier décompressé pour chaque ressource ; un écart important entre les deux confirme que la compression fonctionne. Les en-têtes de réponse HTTP (Content-Encoding: br ou Content-Encoding: gzip) donnent aussi directement la réponse. Des outils d'analyse de performance comme PageSpeed Insights ou GTmetrix signalent explicitement les ressources texte envoyées sans compression, ce qui en fait un point de vérification simple lors d'un audit de vitesse.
Le niveau de compression : un compromis à régler
Gzip et Brotli acceptent tous deux un niveau de compression réglable, généralement de 1 (rapide, compression plus légère) à 9 pour Gzip, voire 11 pour Brotli (compression maximale, plus coûteuse en calcul). Ce réglage a un impact direct sur la charge du serveur :
- Pour du contenu généré dynamiquement à chaque requête, un niveau modéré évite d'ajouter une charge CPU excessive pour un gain marginal.
- Pour des fichiers statiques qui ne changent pas souvent (CSS, JavaScript), une pré-compression au niveau maximal, effectuée une seule fois au moment du déploiement plutôt qu'à chaque requête, permet de profiter du meilleur taux de compression sans aucun coût répété pour le serveur.
Cette distinction entre compression à la volée et pré-compression explique pourquoi deux sites utilisant le même algorithme peuvent afficher des performances assez différentes selon la configuration réellement appliquée côté serveur.
Un détail de configuration piège régulièrement les administrateurs : sur Nginx, les directives gzip_types et brotli_types doivent explicitement lister les types de contenu à compresser (text/html, text/css, application/javascript, application/json...). Un type MIME absent de cette liste ne sera tout simplement jamais compressé, même si la compression est globalement activée sur le serveur. Après toute modification de cette configuration, un contrôle via les outils de développement du navigateur confirme que chaque type de fichier concerné bénéficie bien de la compression attendue.
Faut-il compresser les images avec Gzip ou Brotli ?
Non. Les formats d'image courants (JPEG, PNG, WebP) sont déjà compressés à leur propre niveau ; appliquer une compression texte par-dessus n'apporte quasiment aucun gain et consomme des ressources serveur inutilement.
Brotli remplace-t-il complètement Gzip ?
Dans la pratique, les deux restent souvent configurés ensemble : Brotli est servi en priorité aux navigateurs qui le supportent, Gzip reste la solution de repli pour une compatibilité universelle.
Sur les offres d'hébergement mutualisé et de hébergement WordPress de VSP TECH, la compression Gzip et Brotli est gérée au niveau du serveur web. Pour un contrôle complet de cette configuration, un VPS Linux permet d'ajuster précisément les modules actifs selon les besoins de votre projet.
