...
logo de l'hébergement web

HTTP Compression Thresholds : Configurations optimales pour l'hébergement web

Les seuils de compression HTTP déterminent la taille à partir de laquelle ton serveur compresse les contenus, et contrôlent ainsi directement le TTFB, la charge CPU et la bande passante. Dans ce guide, je te montre des seuils, des niveaux et des réglages d'en-tête concrets pour une livraison rapide ainsi qu'une séparation claire entre le contenu dynamique et statique. Compression.

Points centraux

Je résume d'abord les principaux leviers de réglage afin que tu puisses démarrer de manière ciblée et que tu ne gaspilles pas de cycles CPU inutiles. Je mise sur des seuils clairs, des niveaux appropriés et des en-têtes propres pour que les navigateurs, les proxies et les CDN fonctionnent correctement ensemble. Je distingue les réponses dynamiques des actifs de construction et je contrôle strictement la compression par saut. Je minimise le TTFB en appliquant des niveaux modérés de compression à l'exécution et en obtenant un taux maximal à partir de fichiers précompressés. Je vérifie régulièrement les métriques et ajuste les limites en fonction de la charge réelle, du mélange de fichiers et de la latence, de sorte que ta configuration soit sensiblement plus efficace. plus rapide volonté.

  • Seuil 512-1024 B, standard 1024 B
  • Brotli 3-4 dynamique, 9-11 statique
  • Gzip 5-6 comme fallback
  • MIME Ressources textuelles uniquement
  • Vary et ETag par encodage

Que sont les seuils de compression HTTP ?

Un seuil détermine la taille à partir de laquelle une réponse est compressée et évite que les surcharges d'en-tête ne gonflent artificiellement les petits fichiers. Seuil de rentabilité-considérations. Pour les très petites réponses, l'encodage du contenu peut augmenter la charge utile tout en coûtant de l'UC. C'est pourquoi je fixe généralement une limite inférieure de 1024 octets, voire 512 octets pour les API à haute fréquence avec beaucoup de petites réponses. Des seuils plus petits augmentent le taux de compression, mais ils poussent le TTFB et le CPU lorsque les contenus dynamiques varient fortement. Des seuils plus importants permettent d'économiser du temps de calcul, mais risquent d'entraîner un gaspillage de potentiel pour les fichiers HTML, CSS ou JSON de taille moyenne, qui sont de bonne qualité. Réduction profit.

Brotli vs. Gzip : choix et niveaux

Brotli obtient souvent des taux de 15 à 21 % supérieurs à ceux de Gzip pour les ressources texte, mais il coûte plus cher en CPU par requête, ce dont je tiens compte pour les réponses dynamiques et avec des niveaux modérés amortir. Pour la compression d'exécution, j'utilise Brotli niveau 3-4, pour les assets pré-compressés niveau 9-11. Pour les clients legacy ou les contenus très changeants, je me tourne vers Gzip niveau 5-6. HTTP/2 et HTTP/3 profitent d'une bonne compression, à condition que les tampons de serveur et les points de flush soient correctement définis et qu'aucun flux ne soit bloqué. Ceux qui souhaitent comparer plus en profondeur trouveront dans mon Comparaison Gzip vs. Brotli des valeurs pratiques et des considérations supplémentaires qui facilitent le choix dans le quotidien de l'hébergement. facilitent.

Définir des seuils : Barrières et seuil de rentabilité

Je commence avec 1024 octets comme seuil de base, car l'overhead de l'en-tête est alors clairement surcompensé et l'utilisation du CPU reste raisonnable, en particulier pour HTML et JSON, qui sont très différents. compacter peut être utilisé. Pour les réseaux à très faible latence et les nombreuses répliques d'API minimales, 512 octets peuvent être utiles. En dessous de 512 octets, la compression est rarement rentable, car les coûts de gestion dépassent souvent la réduction de la charge utile. Pour les machines très sollicitées, j'augmente temporairement le seuil jusqu'à ce que les réservoirs de l'unité centrale aient à nouveau de la mémoire tampon. Cet ajustement progressif maintient le TTFB à un niveau bas et préserve la Stabilité de l'ensemble du système.

Comprimer les types MIME de manière ciblée

Je ne compresse que les MIME textuels tels que text/html, text/css, application/javascript, application/json et image/svg+xml, parce qu'ils constituent de véritables Gains tirer. Je ne touche pas aux contenus binaires comme image/*, application/pdf ou font/woff2, car l'effet est faible, voire négatif. Pour les polices, j'utilise directement WOFF2, car il encode déjà efficacement et une compression supplémentaire n'apporte presque rien. J'entretiens pour cela des listes d'autorisation explicites et j'évite les jokers afin qu'aucun fichier binaire ne se retrouve par inadvertance dans l'encodeur. De cette façon, je garde la chaîne de compression propre et j'empêche Corruption par une mauvaise classification.

Statique vs. dynamique : une séparation nette

Je conditionne les assets statiques au préalable en .br et .gz dans le processus de construction ou sur le CDN-Edge et je laisse le serveur utiliser ces variantes directement. livrer. Pour les réponses dynamiques, je définis des niveaux modérés et je garde les tampons suffisamment petits pour que le premier bloc d'octets circule rapidement. Il est important de ne compresser qu'un seul saut dans les chaînes de proxy afin d'éviter une double compression. Sur Origin, je peux désactiver la compression si le CDN s'en charge déjà et la sépare correctement par Vary. Cette séparation permet d'économiser le CPU et d'assurer un débit constant. Temps de réponse même en charge.

Gestion des en-têtes et mise en cache

J'envoie toujours Vary : Accept-Encoding pour que les caches distinguent correctement les variantes et qu'il n'y ait pas de fausses correspondances qui ralentissent les utilisateurs ou altèrent les assets ; cet en-tête est décisif. Pour les fichiers statiques, je définis l'encodage de contenu (br/gzip) plus la longueur de contenu, tandis que les flux dynamiques fonctionnent souvent avec l'encodage de transfert : chunked. Les ETags doivent être spécifiques à l'encodage, sinon le cache renvoie des versions erronées. En outre, je définis de longs TTL de cache pour les assets précompressés et je les sécurise avec Cache-Control : public, immutable, si les hashs de fichiers se trouvent dans le nom. Je donne ici un point de départ compact : Configuration de la compression HTTP, qui te donne les éléments essentiels en Ordre montre.

HTTP/2 et HTTP/3 : flush et tampon

Pour HTTP/2 et HTTP/3, je veille à ce que les points de débordement soient effectués tôt, afin que le HTML et le CSS critiques n'empêchent pas le démarrage du rendu. retardent. Des tampons trop grands peuvent freiner le multiplexage, car un flux domine l'ordonnancement et d'autres contenus attendent. Je garde les premiers blocs de compression petits et j'envoie rapidement, puis j'augmente la taille des blocs pour les fichiers longs. Brotli affiche ici de bons taux avec un overhead modéré, tant que les niveaux 3-4 sont utilisés pour les réponses dynamiques. L'interactivité reste ainsi élevée, tandis que les gros paquets sont traités efficacement. rétrécir.

Pratique : Apache, Nginx, Caddy

Je commence avec des niveaux modérés et un seuil de 1024 octets, puis je contrôle systématiquement le TTFB et le CPU, au lieu de fixer aveuglément des taux maximums. forcer. Pour Apache, j'active mod_deflate ou mod_brotli et je ne définis que les types MIME souhaités. Dans Nginx, je définis gzip_min_length 1024 et Brotli sur on, que je combine avec brotli_static pour les fichiers précompressés. Caddy propose des commutateurs simples avec encodings gzip zstd br ; je traite séparément les chemins dynamiques de bas niveau. Par expérience, il vaut la peine de jeter un coup d'œil à Charge CPU et niveau de compression, La combinaison de la proportion de réponses dynamiques et du nombre de noyaux atteint souvent la limite du nombre de réponses dynamiques. met.

Apache Exemple (mod_deflate/mod_brotli) :

AddOutputFilterByType DEFLATE text/html text/css application/javascript application/json image/svg+xml
 SetOutputFilter DEFLATE
 DeflateCompressionLevel 6
 DeflateBufferSize 64k



 AddOutputFilterByType BROTLI_COMPRESS text/html text/css application/javascript application/json image/svg+xml
 BrotliCompressionQuality 4
 BrotliWindowSize 22

Nginx exemple :

gzip on ;
gzip_min_length 1024 ;
gzip_types text/plain text/css application/json application/javascript image/svg+xml ;
gzip_comp_level 5 ;

brotli on ;
brotli_comp_level 4 ;
brotli_static on ;
brotli_types text/plain text/css application/json application/javascript image/svg+xml ;

Monitoring et recherche d'erreurs

Je mesure le TTFB, l'utilisation du CPU par worker et la taille des transferts par type pour savoir où la compression est utile et où elle est inutile. nuit à. Si le TTFB augmente après l'activation, je baisse le niveau ou j'augmente le seuil. En cas d'effets étranges, je vérifie d'abord la double compression, les en-têtes Vary manquants ou les types MIME mal reconnus. Je jette également un coup d'œil aux politiques CDN et WAF, car un deuxième saut avec compression déplace la charge et détériore souvent le temps jusqu'au premier octet. Des outils comme WebPageTest et Browser-DevTools suffisent pour un premier test. Audit complètement.

Points de mesure et valeurs recommandées

Je m'en tiens à quelques valeurs de référence claires, afin que la configuration reste maîtrisable tout en conservant un haut niveau de qualité. Effet montre. Le tableau suivant résume les seuils, les niveaux et les indications de mise en cache utiles. Il couvre les piles web typiques avec HTML, CSS, JS, JSON, SVG et les polices. Adapte le seuil en fonction de la charge, de la réserve de CPU et de la proportion de réponses dynamiques. Commence de manière conservatrice, mesure et déplace les curseurs de manière itérative par petites touches. Étapes.

Ressource Seuil (octets) Dynamique (niveau) Statique (niveau) Indication de la cache
HTML 1024 Br 3–4 / Gz 5–6 Br 9-11 (pré-comprimé) TTL long pour les noms de hachage
CSS/JS 1024 rarement dynamique Br 9-11 (pré-comprimé) immuable, variantes par hachage
JSON (APIs) 512-1024 Br 3–4 / Gz 5–6 pas courant Maintenir la cohérence des en-têtes
SVG 1024 rarement dynamique Br 9-11 Tester les requêtes Range
Fonts (WOFF2) pas de pas de pas de ne pas comprimer davantage
Images (PNG/JPEG/WEBP) pas de pas de pas de optimisation séparée
PDF pas de pas de pas de Éviter l'encodage

Les ECstd dans le contexte : quand cela est-il utile, quand cela ne l'est pas ?

J'évalue Zstd de manière indépendante parce qu'il est excellent. Débits avec une bonne compression. Dans l'environnement du navigateur, la prise en charge est toutefois hétérogène, raison pour laquelle je ne déploie généralement pas Zstd comme encodage principal pour l'utilisateur final. Entre les services internes ou sur le backbone CDN, Zstd peut être très utile pour maintenir le trafic CDN Origin de manière efficace. Sur le Edge, je reste avec Brotli (pour le texte) et Gzip comme fallback jusqu'à ce qu'une base de clients largement supportée garantisse que les variantes soient correctement négociées. Dans Caddy, je laisse Zstd actif en option, mais je donne la priorité aux Négociation Brotli avant Gzip pour équilibrer la compatibilité et les performances.

Requêtes de plage, téléchargements et fichiers précompressés

Je contrôle séparément les téléchargements volumineux (p. ex. PDF, CSV). Pour les données binaires, je désactive généralement l'encodage du contenu et je fournis l'identité (identité) pour que les requêtes de plage fonctionnent correctement et que les téléchargements de résumés restent stables. Pour les fichiers texte statiques avec des variantes .br/.gz, je m'assure que le serveur sélectionne la bonne variante en fonction de la demande du client et que la longueur du contenu, l'encodage du contenu et l'ETag sont cohérents. En cas de demandes partielles de variantes comprimées, des plages d'octets doivent être utilisées pour l'authentification. compressé Si la pile ne gère pas cela de manière robuste, je fournis la version non compressée pour les demandes de plage. Cela permet d'atténuer les cas de bord et d'éviter les reprises erronées.

Sécurité : compression et fuites de données

Je tiens compte des canaux latéraux liés à la compression tels que BREACH. Si les réponses reflètent des contenus dépendant de secrets (jetons, ID de session) proches des entrées contrôlables par l'attaquant, je désactive la compression de manière sélective ou je découple les secrets (padding, séparation dans des champs propres non comprimés). Pour les chemins de connexion et de paiement, il est judicieux de désactiver la compression par l'en-tête ou le jeu de règles. Les cookies avec des en-têtes Set-Cookie ne sont pas critiques, l'important est la Réponse-charge utile. Je tiens donc à disposition des filtres qui ciblent le chemin d'accès, MIME ou certains modèles afin d'imposer facilement des heuristiques.

Chaînes CDN et proxy : une compression par saut

Je définis clairement sur quel saut la compression doit être effectuée : Soit sur le Edge (CDN) ou à l'origine, pas les deux. Si le CDN compresse, j'omets l'encodage du contenu à l'origine et j'envoie l'encodage Vary : Accept pour que l'Edge construise des variantes correctes. Si l'Origin doit fournir des assets pré-compressés (.br/.gz), je configure l'Edge de manière à ce qu'il puisse les utiliser. transparent et ne le transforme pas à nouveau. Si je souhaite empêcher strictement les transformations par des proxies intermédiaires (par exemple pour la conformité), je définis le contrôle de cache : no-transform - je planifie alors la compression de manière ciblée à l'origine. Pour le debugging, je note quel hop Compression et garde les métriques séparées pour chaque saut.

Streaming, SSE, gRPC et WebSockets

Pour les Server-Sent Events (SSE) et les flux similaires, j'évite les niveaux élevés et les grand Tampons ; sinon, la latence augmente considérablement. J'utilise des petits blocs, des flushes fréquents et une compression plus désactivée lorsque l'interactivité est prioritaire. gRPC utilise sa propre compression de messages et fonctionne via HTTP/2 - ici, j'évite l'encodage de contenu HTTP supplémentaire afin d'éviter les doublons. Il en va de même pour les WebSockets : le Per-Message-Deflate peut être utile, mais je ne l'active que pour les canaux vraiment chargés en texte et j'observe la CPU-Effet exact.

Serveur d'applications : Définir les paramètres de la couche d'application de manière ciblée

Je préfère régler les seuils dans le proxy Edge/Reverse, mais lorsque les frameworks compressent, je règle des valeurs cohérentes pour que rien ne fonctionne en sens inverse.

  • Node.js/ExpressJe fixe un seuil de 1024 octets et des niveaux modérés. Les assets statiques précompressés sont directement traités par le gestionnaire de statiques, je ne compresse les routes dynamiques que pour les MIME de texte.
  • Allez surJe choisis une liste d'autorisation claire des MIME par gestionnaire et j'ignore la compression en dessous de 1 Ko. Pour les longs flux, je garde les write-flushs petits afin de ne pas surcharger le first paint. retardent.
  • Java/Tomcat: J'utilise compressionMinSize 1024 et je gère explicitement la liste MIME ; les types binaires sont laissés de côté.

Tomcat Exemple (server.xml Connector) :

<Connector port="8080" protocol="HTTP/1.1"
    compression="on"
    compressionMinSize="1024"
    noCompressionUserAgents=""
    compressableMimeType="text/html,text/css,application/javascript,application/json,image/svg+xml"
    URIEncoding="UTF-8" />

Important : si un proxy en amont (Nginx, Caddy) compresse déjà, je désactive la compression App-Layer pour Travail en double d'éviter les conflits et de ne laisser qu'une seule couche de responsabilité.

Seuils adaptatifs et contrôle de la charge

Je pense en termes de politiques plutôt qu'en termes de valeurs rigides. Sous une charge CPU élevée, je lève la Seuil (par ex. de 1024 à 2048 octets) ou abaisse le niveau de Brotli (par ex. de 4 à 2) pour les réponses dynamiques. Si la charge diminue, j'augmente à nouveau les valeurs. Cela peut être contrôlé via un drapeau de caractéristique, des variables Env ou un simple rechargement. Sur les nœuds avec peu de CPU, je réserve la compression pour les MIME les plus importants (HTML/JSON), tandis que CSS/JS arrive presque exclusivement précompressé du stockage/CDN. Ces Définition des priorités maintient le TTFB stable au lieu de basculer dans les pics.

Playbook d'essai : vérification rapide

Je vérifie l'effet en quelques étapes reproductibles :

  • Négociation: curl -I -H „Accept-Encoding : br“ https://example.com - vérifie l'encodage du contenu, Vary et la longueur du contenu.
  • Fallback: curl -I -H „Accept-Encoding : gzip“ - gzip attendu ? ETag différent de Brotli ?
  • Sans compression: curl -I -H „Accept-Encoding : identity“ - Comparer la différence de taille et le TTFB.
  • gamme: curl -I -H „Range : bytes=0-1023“ - le serveur accepte-t-il correctement des sous-domaines, et la plage de contenu correspond-elle ?
  • DevToolsComparer la taille „sur le réseau“ et la taille „des ressources“ afin de déterminer la taille réelle des ressources. Économies de voir.

En bref

Définissez le seuil à 1024 octets comme point de départ rapide, vérifiez le TTFB et le CPU, et affinez vos réglages avec des petits Adaptations après . Utilise Brotli 3-4 pour les contenus dynamiques et 9-11 pour les assets pré-compressés, garde Gzip 5-6 en réserve. Ne compresse que les MIME texte et livre directement les fichiers précompressés afin que les actifs de construction restent légers en permanence. Veille à Vary : Accept-Encoding, Content-Encoding et ETags spécifiques à l'encodage, afin que les caches fonctionnent correctement. Avec des seuils de compression HTTP bien définis, tu accélères sensiblement la livraison sans surcharger la machine avec des calculs inutiles. bloquer.

Derniers articles