...
logo di web hosting

Soglie di compressione HTTP: configurazioni ottimali per l'hosting web

Le soglie di compressione HTTP determinano le dimensioni con cui il vostro server comprime i contenuti e quindi controllano direttamente il TTFB, il carico della CPU e la larghezza di banda. In questa guida vi mostrerò le soglie, i livelli e le impostazioni delle intestazioni specifiche per una consegna veloce, nonché una chiara separazione tra compressione dinamica e statica. Compressione.

Punti centrali

Riassumerò prima le regolazioni più importanti, in modo che possiate iniziare in modo mirato ed evitare di sprecare inutili cicli di CPU. Mi affido a soglie chiare, livelli adeguati e intestazioni pulite, in modo che browser, proxy e CDN lavorino insieme correttamente. Distinguo tra risposte dinamiche e risorse di costruzione e tengo sotto stretto controllo la compressione per hop. Riduco al minimo il TTFB con livelli moderati di compressione runtime e ottengo la massima velocità dai file precompressi. Controllo regolarmente le metriche e regolo i limiti in base al carico del mondo reale, al mix di file e alla latenza, in modo che la vostra configurazione sia sensibilmente più efficiente. più veloce volontà.

  • Soglia 512-1024 B, standard 1024 B
  • Grissino 3-4 dinamico, 9-11 statico
  • Gzip 5-6 come ripiego
  • MIME Solo risorse testuali
  • Variare e ETag per codifica

Cosa sono le soglie di compressione HTTP?

Una soglia determina la dimensione al di sopra della quale una risposta viene compressa e impedisce che l'overhead dell'intestazione gonfi artificialmente i file più piccoli; è proprio questo il caso in cui Pareggio-Considerazioni. Con risposte molto piccole, la codifica del contenuto può aumentare il carico utile e allo stesso tempo costare alla CPU. Per questo motivo, di solito imposto un limite inferiore di 1024 byte, o di 512 byte per le API ad alta frequenza con molte risposte piccole. Le soglie più piccole aumentano il rapporto di compressione, ma aumentano il TTFB e la CPU quando il contenuto dinamico varia notevolmente. Soglie più alte fanno risparmiare tempo di calcolo, ma rischiano di sprecare potenziale con file HTML, CSS o JSON di medie dimensioni e di buona qualità. Riduzione profitto.

Brotli vs. Gzip: scelta e livelli

Brotli raggiunge spesso tassi migliori del 15-21% rispetto a Gzip per le risorse di testo, ma costa più CPU per richiesta, cosa che tengo in considerazione per le risposte dinamiche e con livelli moderati. cuscino. Per la compressione runtime uso Brotli livello 3-4, per le risorse preconfezionate livello 9-11. Per i client legacy o per i contenuti che cambiano molto uso Gzip livello 5-6. HTTP/2 e HTTP/3 beneficiano di una buona compressione, a patto che i buffer del server e i punti di flush siano impostati correttamente e che non si verifichino stalli del flusso. Se volete fare un confronto più approfondito, potete trovare ulteriori informazioni nel mio Confronto Gzip vs Brotli ulteriori valori e considerazioni pratiche che rendono la scelta di tutti i giorni. facilitare.

Stabilire le soglie: Guard rail e break-even

Inizio con 1024 byte come soglia di base, perché l'overhead dell'intestazione è chiaramente sovracompensato e l'utilizzo della CPU rimane ragionevole, soprattutto con HTML e JSON, che differiscono notevolmente. condensare congedo. Con reti a bassissima latenza e molte risposte API minime, 512 byte possono essere utili. La compressione è raramente utile al di sotto dei 512 byte, perché i costi di amministrazione spesso superano la riduzione del carico utile. Nel caso di macchine molto utilizzate, aumento temporaneamente la soglia fino a quando i serbatoi della CPU non dispongono nuovamente di buffer. Questa regolazione graduale consente di mantenere basso il TTFB e di conservare il Stabilità dell'intero sistema.

Comprimere i tipi MIME in modo specifico

Comprimo solo i MIME di testo come text/html, text/css, application/javascript, application/json e image/svg+xml, perché possono essere usati per motivi di ridondanza. Vincite trascinare. Lascio inalterato il contenuto binario come image/*, application/pdf o font/woff2, poiché l'effetto è minimo o negativo. Per i font, uso direttamente WOFF2 perché codifica già in modo efficiente e un'ulteriore compressione è poco utile. Mantengo elenchi di permessi espliciti ed evito i caratteri jolly, in modo che nessun file binario finisca accidentalmente nel codificatore. In questo modo mantengo la catena di compressione pulita e impedisco che Corruzione a causa di una classificazione errata.

Statica e dinamica: una separazione netta

Nel processo di compilazione o sul bordo del CDN impacchetto le risorse statiche in anticipo come .br e .gz e lascio che il server utilizzi direttamente queste varianti. consegnare. Per le risposte dinamiche, imposto livelli moderati e mantengo i buffer abbastanza piccoli in modo che il primo blocco di byte scorra rapidamente. È importante comprimere solo un hop nelle catene di proxy, in modo da evitare una doppia compressione. Posso disattivare la compressione sull'origine se il CDN l'ha già effettuata e la separa correttamente tramite Vary. Questa separazione fa risparmiare CPU e garantisce una costante Tempi di risposta anche sotto carico.

Gestione delle intestazioni e cache

Invio sempre Vary: Accept-Encoding in modo che le cache distinguano correttamente le varianti e non ci siano errori che rallentino gli utenti o falsifichino le risorse; questa intestazione è decisivo. Per i file statici, imposto la codifica del contenuto (br/gzip) più la lunghezza del contenuto, mentre i flussi dinamici spesso vengono eseguiti con la codifica di trasferimento: chunked. Gli ETag devono essere specifici per la codifica, altrimenti la cache fornirà versioni errate. Ho anche impostato lunghi TTL della cache per gli asset precompressi e li ho protetti con il controllo della cache: pubblico, immutabile se gli hash dei file sono nel nome. Qui fornisco un punto di partenza compatto: Configurazione della compressione HTTP, che vi mostrerà gli elementi costitutivi più importanti della Sequenza spettacoli.

HTTP/2 e HTTP/3: Flush e buffer

Con HTTP/2 e HTTP/3, faccio attenzione ai punti di flush precoci, in modo che HTML e CSS critici non ritardino l'avvio del rendering. ritardo. I buffer troppo grandi possono rallentare il multiplexing perché un flusso domina la programmazione e gli altri contenuti sono in attesa. Mantengo i primi blocchi di compressione piccoli e invio rapidamente, quindi aumento le dimensioni dei blocchi per i file lunghi. Brotli mostra buone velocità con un overhead moderato, purché si utilizzi il livello 3-4 per le risposte dinamiche. In questo modo si mantiene alta l'interattività, mentre i bundle di grandi dimensioni sono efficienti. strizzacervelli.

Pratica: Apache, Nginx, Caddy

Inizio con livelli moderati e una soglia di 1024 byte e poi controllo sistematicamente il TTFB e la CPU invece di impostare alla cieca le velocità massime. applicazione. Per Apache, attivo mod_deflate o mod_brotli e definisco solo i tipi MIME desiderati. In Nginx imposto gzip_min_length 1024 e Brotli su on, combinandolo con brotli_static per i file precompressi. Caddy offre semplici interruttori con le codifiche gzip zstd br; io gestisco separatamente i percorsi dinamici con livelli bassi. Per esperienza, vale la pena dare un'occhiata a Carico della CPU e livello di compressione, perché la combinazione della percentuale di risposte dinamiche e del numero di core spesso supera il limite. set.

Apache Esempio (mod_deflate/mod_brotli):

AddOutputFilterByType DEFLATE text/html text/css application/javascript application/json image/svg+xml
 Imposta filtro di uscita DEFLATE
 DeflateCompressionLevel 6
 DeflateBufferSize 64k



 AddOutputFilterByType BROTLI_COMPRESS text/html text/css application/javascript application/json image/svg+xml
 BrotliQualità di compressione 4
 BrotliWindowSize 22

Nginx Esempio:

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;

Monitoraggio e risoluzione dei problemi

Misuro il TTFB, l'utilizzo della CPU per lavoratore e la dimensione del trasferimento per tipo, in modo da capire dove la compressione è utile e dove è necessaria. danni. Se il TTFB aumenta dopo l'attivazione, abbasso il livello o aumento la soglia. Se si verificano effetti strani, verifico innanzitutto la presenza di una doppia compressione, di intestazioni Vary mancanti o di tipi MIME riconosciuti in modo errato. Inoltre, controllo le politiche CDN e WAF, perché un secondo hop con compressione sposta il carico e spesso peggiora il tempo al primo byte. Strumenti come WebPageTest e Browser-DevTools sono sufficienti per un controllo iniziale. Audit completamente.

Punti di misura e valori consigliati

Mi attengo a pochi e chiari parametri, in modo che la configurazione rimanga gestibile e raggiunga comunque un alto livello di qualità. Effetto mostra. La tabella seguente riassume le soglie, i livelli e le istruzioni di caching utili. Copre gli stack web tipici con HTML, CSS, JS, JSON, SVG e font. Regolare la soglia in base al carico, alla riserva di CPU e alla percentuale di risposte dinamiche. Iniziare in modo conservativo, misurare e spostare iterativamente i cursori con piccoli incrementi. Passi.

Risorse Soglia (byte) Dinamico (livello) Statico (livello) Suggerimento per la cache
HTML 1024 Br 3–4 / Gz 5–6 Fr. 9-11 (precompresso) TTL lungo per i nomi hash
CSS/JS 1024 Raramente dinamico Fr. 9-11 (precompresso) immutabile, varianti per hash
JSON (API) 512-1024 Br 3–4 / Gz 5–6 non comune Mantenere coerente l'intestazione
SVG 1024 Raramente dinamico Br 9–11 Richieste di campo prova
Caratteri (WOFF2) nessuno nessuno nessuno Non comprimere ulteriormente
Immagini (PNG/JPEG/WEBP) nessuno nessuno nessuno Ottimizzazione separata
PDF nessuno nessuno nessuno Evitare la codifica

Zstd nel contesto: quando ha senso, quando no

Valuto Zstd in maniera indipendente perché ha un'ottima Velocità di trasmissione con una buona compressione. Nell'ambiente dei browser, tuttavia, il supporto è eterogeneo, motivo per cui di solito non distribuisco Zstd come codifica principale per l'utente finale. Tra i servizi interni o sul percorso della dorsale CDN, Zstd può essere molto utile per mantenere efficiente il traffico di Origin CDN. Ai margini, mantengo Brotli (per il testo) e Gzip come ripiego finché una base di clienti ampiamente supportata non garantisce che le varianti siano negoziate correttamente. In Caddy, lascio Zstd facoltativamente attivo, ma do priorità al traffico di Negoziazione Brotli prima di Gzip per bilanciare compatibilità e prestazioni.

Richieste di gamma, download e file precompressi

Controllo separatamente i download di grandi dimensioni (ad es. PDF, CSV). Per i dati binari, di solito disattivo la codifica dei contenuti e fornisco l'identità (identità) in modo che le richieste di intervallo funzionino correttamente e i download di ripresa rimangano stabili. Per i file di testo statici con varianti .br/.gz, mi assicuro che il server selezioni la variante corretta a seconda della richiesta del client e che la lunghezza del contenuto, la codifica del contenuto e l'ETag siano coerenti. Per le richieste parziali di varianti compresse, gli intervalli di byte per l'attributo compresso lunghezza - se lo stack non gestisce questo aspetto in modo robusto, fornisco la versione non compressa per le richieste di intervallo. Questo attenua i casi limite e previene i riavvii errati.

Sicurezza: compressione e fughe di dati

Tengo conto dei canali secondari legati alla compressione, come ad esempio BREAK. Se le risposte riflettono contenuti dipendenti dal segreto (token, ID di sessione) vicino a input che possono essere controllati dall'attaccante, disattivo selettivamente la compressione o disaccoppio i segreti (padding, separazione in campi separati non compressi). Per i percorsi di login e di pagamento, ha senso disattivare la compressione utilizzando intestazioni o regole. I cookie con le intestazioni dei cookie impostate non sono critici, ciò che è importante è l'elemento Risposta-payload. Per questo motivo ho già pronti dei filtri che mirano al percorso, al MIME o a certi modelli, in modo da applicare facilmente l'euristica.

Catene CDN e proxy: una compressione per hop

Definisco chiaramente il punto in cui avviene la compressione: O al punto Bordo (CDN) o sull'origine, non su entrambi. Se il CDN comprime, ometto la codifica del contenuto sull'origine e invio la codifica Vary: Accept, in modo che Edge crei varianti corrette. Se l'origine deve fornire risorse precompresse (.br/.gz), configuro Edge per inviare questi file al CDN. Trasparente e non lo trasforma di nuovo. Se voglio impedire rigorosamente le trasformazioni da parte dei proxy intermedi (ad esempio per la conformità), imposto Cache-Control: no-transform - quindi pianifico la compressione specificamente all'origine. Per il debug, prendo nota di quale hop il file Compressione e mantenere le metriche separate per ogni hop.

Streaming, SSE, gRPC e WebSockets

Per gli eventi inviati dal server (SSE) e flussi simili, evito livelli alti e grande buffer; altrimenti la latenza aumenta sensibilmente. Uso blocchi piccoli, flush frequenti e una compressione più disattivata se l'interattività ha la priorità. gRPC usa la propria compressione dei messaggi ed è eseguito tramite HTTP/2; in questo caso evito la codifica aggiuntiva del contenuto HTTP per evitare duplicazioni. Lo stesso vale per i WebSocket: deflate per messaggio può essere utile, ma lo attivo solo per i canali veramente pesanti e osservo il comportamento di CPU-Effetto esatto.

Server di applicazioni: Impostare le impostazioni del livello di applicazione in modo specifico

Preferisco controllare le soglie nel proxy edge/reverse, ma quando i quadri comprimono, imposto valori coerenti in modo che nulla vada contro l'altro.

  • Node.js/ExpressHo impostato una soglia di 1024 byte e livelli moderati. Il gestore statico serve direttamente risorse statiche precompresse, comprimo solo i percorsi dinamici per i MIME di testo.
  • Vai aSeleziono un elenco chiaro di MIME consentiti per ogni gestore e salto la compressione al di sotto di 1 KB. Per i flussi lunghi, mantengo i flussaggi in scrittura piccoli, in modo da non sovraccaricare il primo paint. ritardo.
  • Java/TomcatUso compressionMinSize 1024 e mantengo l'elenco MIME in modo esplicito; i tipi binari sono esclusi.

Tomcat Esempio (connettore server.xml):

<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" />

Importante: se un proxy upstream (Nginx, Caddy) sta già comprimendo, disattivo la compressione del livello dell'applicazione per Duplicazione del lavoro e lasciare che un solo strato si assuma la responsabilità.

Soglie adattive e controllo del carico

Penso in termini di politiche invece che di valori rigidi. In presenza di un elevato carico di CPU, alzo il Soglia temporaneamente (ad esempio da 1024 a 2048 byte) o abbassare il livello di Brotli (ad esempio da 4 a 2) per le risposte dinamiche. Se il carico diminuisce, aumento di nuovo i valori. Questo può essere controllato tramite un flag di funzionalità, variabili Env o un semplice reload. Sui nodi con poca CPU, riservo la compressione ai MIME più importanti (HTML/JSON), mentre CSS/JS vengono quasi esclusivamente precompressi dallo storage/CDN. Questo Definizione delle priorità mantiene stabile il TTFB, invece di fargli raggiungere i picchi.

Test playbook: verifica rapida

Verifico l'effetto con alcuni passaggi riproducibili:

  • Negoziazione: curl -I -H „Accept-Encoding: br“ https://example.com - controlla Content-Encoding, Vary e Content-Length.
  • Fallbackcurl -I -H „Accept-Encoding: gzip“ - previsto gzip? ETag diverso da Brotli?
  • Senza compressione: curl -I -H „Accept-Encoding: identity“ - Confronta la differenza di dimensione e TTFB.
  • Gammacurl -I -H „Range: bytes=0-1023“ - il server accetta correttamente i subrange e il Content-Range è adeguato?
  • Strumenti di sviluppoConfrontare la dimensione „Oltre la rete“ rispetto alla „Dimensione della risorsa“ per determinare la dimensione reale. Risparmio da vedere.

Riassumendo brevemente

Impostare la soglia a 1024 byte come punto di partenza, controllare TTFB e CPU e affinare le impostazioni con piccoli Regolazioni dopo. Usare Brotli 3-4 per i contenuti dinamici e 9-11 per le risorse precompresse, mantenendo Gzip 5-6 come ripiego. Comprimete solo i MIME di testo e consegnate direttamente i file precompressi per mantenere le risorse della build leggere e durature. Prestare attenzione a Vary: Accept-Encoding, Content-Encoding e agli ETag specifici per la codifica, in modo che le cache funzionino correttamente. Con le soglie di compressione HTTP impostate correttamente, è possibile accelerare notevolmente la consegna senza appesantire la macchina con un lavoro di calcolo non necessario. blocco.

Articoli attuali