Règle de décision et limites
Gzip et Brotli sont des encodages de contenu HTTP qui réduisent le nombre d'octets de texte transférés lorsque le serveur et le navigateur négocient un encodage pris en charge. La négociation se fait entre le client et le serveur : le navigateur annonce les encodages qu'il accepte, et le serveur renvoie une représentation accompagnée de l'en-tête Content-Encoding. Cette technique est surtout utile pour le HTML, le CSS, le JavaScript, le JSON et le SVG, qui se compressent bien, mais pas pour les images ou les archives déjà compressées.
Comment la vérifier
Demandez un document type avec et sans encodages acceptés, puis comparez les en-têtes, la taille transférée, la variation du cache et le décodage réussi. Vérifiez qu'un intermédiaire ne sert pas une représentation Brotli à un client qui ne l'a pas négociée.
Démarche pratique
Activez la compression au niveau qui assure la diffusion, conservez Vary: Accept-Encoding lorsque le cache partagé l'exige, et vérifiez la réponse sans cache comme la réponse mise en cache. Mesurez les octets transférés séparément du temps de réponse du serveur et du travail de rendu.
Erreurs courantes et limites de la mesure
Un transfert plus léger ne prouve pas une interaction plus rapide. La compression ne corrige ni un traitement lent côté serveur, ni des images surdimensionnées, ni un JavaScript trop volumineux, ni une configuration de cache qui livre la mauvaise variante. L'erreur la plus fréquente consiste à compresser des médias déjà compressés, ou à juger la compression à partir d'un fichier local non compressé.