...
webhostinglogo

HTTP-compressiedrempels: optimale configuraties voor webhosting

HTTP-compressiedrempels bepalen de grootte waarmee je server inhoud comprimeert en hebben dus rechtstreeks invloed op TTFB, CPU-belasting en bandbreedte. In deze handleiding laat ik je specifieke drempelwaarden, niveaus en headerinstellingen zien voor snelle levering en een duidelijk onderscheid tussen dynamische en statische compressie. Compressie.

Centrale punten

Ik zal eerst de belangrijkste aanpassingen samenvatten zodat je gericht aan de slag kunt en geen onnodige CPU-cycli verspilt. Ik vertrouw op duidelijke drempels, geschikte niveaus en schone headers zodat browsers, proxy's en CDN's correct samenwerken. Ik maak onderscheid tussen dynamische reacties en build assets en houd compressie per hop strikt onder controle. Ik minimaliseer TTFB met gematigde niveaus van runtime compressie en haal maximale snelheid uit voorgecomprimeerde bestanden. Ik controleer regelmatig de statistieken en pas de limieten aan de werkelijke belasting, bestandsmix en latentie aan, zodat je setup merkbaar efficiënter wordt. sneller wil.

  • Drempel 512-1024 B, standaard 1024 B
  • Broodstengel 3-4 dynamisch, 9-11 statisch
  • Gzip 5-6 als noodoplossing
  • MIME Alleen tekstbronnen
  • Variëren en ETag per codering

Wat zijn HTTP-compressiedrempels?

Een drempelwaarde bepaalt de grootte waarboven een antwoord wordt gecomprimeerd en voorkomt dat headeroverhead kleine bestanden kunstmatig opblaast; dit is precies waar Break-even-overwegingen. Bij zeer kleine reacties kan het coderen van inhoud de payload verhogen en tegelijkertijd CPU kosten. Daarom stel ik meestal een ondergrens in van 1024 bytes, of 512 bytes voor hoogfrequente API's met veel kleine reacties. Kleinere drempels verhogen de compressieverhouding, maar ze drijven TTFB en CPU op wanneer dynamische inhoud sterk varieert. Grotere drempels besparen rekentijd, maar riskeren verspilling van potentieel bij middelgrote HTML-, CSS- of JSON-bestanden die van goede kwaliteit zijn. Vermindering winst.

Brotli vs. Gzip: Keuze en niveaus

Brotli haalt vaak 15-21 procent betere tarieven dan Gzip voor tekstbronnen, maar kost meer CPU per verzoek, wat ik meereken voor dynamische reacties en met gematigde niveaus kussen. Voor runtime compressie gebruik ik Brotli level 3-4, voor voorverpakte assets level 9-11. Voor legacy clients of sterk wisselende content gebruik ik Gzip level 5-6. HTTP/2 en HTTP/3 profiteren van goede compressie, zolang de serverbuffers en flush points goed zijn ingesteld en de stream niet stokt. Als je een diepere vergelijking wilt maken, kun je meer informatie vinden in mijn Vergelijking Gzip vs. Brotli aanvullende praktische waarden en overwegingen die de keuze in alledaagse hosting maken vergemakkelijken.

Stel drempels in: Hekken en break-even

Ik begin met 1024 bytes als basisdrempel, omdat header overhead dan duidelijk wordt overgecompenseerd en het CPU-gebruik redelijk blijft, vooral met HTML en JSON, die sterk verschillen. condenseren vertrekken. Met netwerken met een zeer lage latentie en veel minimale API-antwoorden kan 512 bytes nuttig zijn. Compressie is zelden de moeite waard onder 512 bytes omdat de administratiekosten vaak hoger zijn dan de vermindering van de payload. In het geval van zwaar gebruikte machines verhoog ik tijdelijk de drempel totdat de CPU reservoirs weer buffers hebben. Deze geleidelijke aanpassing houdt TTFB laag en behoudt de Stabiliteit van het totale systeem.

Specifiek MIME-types comprimeren

Ik comprimeer alleen tekst-MIME's zoals text/html, text/css, application/javascript, application/json en image/svg+xml, omdat ze gebruikt kunnen worden voor redundantie. Winsten slepen. Ik laat binaire inhoud zoals image/*, application/pdf of font/woff2 ongemoeid, omdat het effect klein tot negatief is. Voor lettertypen gebruik ik WOFF2 direct omdat het al efficiënt codeert en verdere compressie weinig nut heeft. Ik onderhoud expliciete toestemmingslijsten en vermijd jokertekens zodat er geen binaire bestanden per ongeluk in de encoder terechtkomen. Op deze manier houd ik de compressieketen schoon en voorkom ik Corruptie door verkeerde classificatie.

Statisch vs. dynamisch: duidelijke scheiding

Ik verpak statische assets in het buildproces of aan de CDN-rand vooraf als .br en .gz en laat de server deze varianten direct gebruiken. leveren. Voor dynamische reacties stel ik gematigde niveaus in en houd ik de buffers klein genoeg zodat het eerste byteblok snel stroomt. Het is belangrijk om slechts één hop in proxy-ketens te comprimeren, zodat er geen dubbele compressie optreedt. Ik kan compressie op de Origin uitschakelen als het CDN het al heeft gedaan en het correct scheidt via Vary. Deze scheiding bespaart CPU en zorgt voor een constante Reactietijden zelfs onder belasting.

Headerbeheer en caching

Ik stuur altijd Vary: Accept-Encoding zodat caches varianten correct onderscheiden en er geen missers zijn die gebruikers vertragen of assets vervalsen; deze header is beslissend. Voor statische bestanden gebruik ik inhoudscodering (br/gzip) plus inhoudslengte, terwijl dynamische streams vaak draaien met overdrachtscodering: chunked. ETags moeten encoding-specifiek zijn, anders zal de cache onjuiste versies leveren. Ik stel ook lange cache TTL's in voor voorgecomprimeerde assets en beveilig ze met cache control: public, immutable, als de hashes van het bestand in de naam staan. Ik geef hier een compact uitgangspunt: HTTP-compressie configuratie, die je de belangrijkste bouwstenen laat zien in Volgorde shows.

HTTP/2 en HTTP/3: Spoelen en bufferen

Met HTTP/2 en HTTP/3 let ik op vroege doorspoelpunten, zodat kritieke HTML en CSS de start van de render niet vertragen. vertraging. Te grote buffers kunnen multiplexing vertragen omdat één stream de planning domineert en andere inhoud staat te wachten. Ik houd de eerste compressieblokken klein en verstuur snel, verhoog dan de blokgrootte voor lange bestanden. Brotli laat goede snelheden zien met matige overhead zolang niveau 3-4 wordt gebruikt voor dynamische reacties. Dit houdt de interactiviteit hoog, terwijl grote bundels efficiënt zijn. krimp.

Praktijk: Apache, Nginx, Caddy

Ik begin met gematigde niveaus en een drempel van 1024 bytes en controleer dan systematisch de TTFB en CPU in plaats van blindelings maximumsnelheden in te stellen. handhaven. Voor Apache activeer ik mod_deflate of mod_brotli en definieer ik alleen de gewenste MIME-types. In Nginx zet ik gzip_min_length 1024 en Brotli aan, dit combineer ik met brotli_static voor voorgecomprimeerde bestanden. Caddy biedt eenvoudige schakelaars met coderingen gzip zstd br; ik behandel dynamische paden met lage niveaus apart. Uit ervaring is het de moeite waard om te kijken naar CPU-belasting en compressieniveau, omdat de combinatie van het aandeel dynamische reacties en het aantal kernen vaak de limiet overschrijdt. zet.

Apache Voorbeeld (mod_deflate/mod_brotli):

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



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

Nginx Voorbeeld:

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

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

Bewaking en probleemoplossing

Ik meet TTFB, CPU-gebruik per werker en overdrachtsgrootte per type, zodat ik kan zien waar compressie helpt en waar het nodig is. schaadt. Als TTFB toeneemt na activering, verlaag ik het niveau of verhoog ik de drempel. Als er vreemde effecten zijn, controleer ik eerst op dubbele compressie, ontbrekende Vary-headers of verkeerd herkende MIME-typen. Ik kijk ook naar het CDN- en WAF-beleid, want een tweede hop met compressie verschuift de belasting en verslechtert vaak de tijd tot de eerste byte. Tools zoals WebPageTest en Browser-DevTools zijn voldoende voor een eerste controle. Controle volledig.

Meetpunten en aanbevolen waarden

Ik houd me aan een paar duidelijke parameters, zodat de configuratie beheersbaar blijft en toch een hoog kwaliteitsniveau bereikt. Effect laat zien. De volgende tabel geeft een overzicht van nuttige drempelwaarden, niveaus en caching-instructies. Het gaat om typische webstacks met HTML, CSS, JS, JSON, SVG en lettertypen. Pas de drempelwaarde aan afhankelijk van de belasting, het CPU-reservoir en het aandeel dynamische reacties. Begin conservatief, meet en verplaats de schuifregelaars iteratief in kleine stappen. Stappen.

Bron Drempel (bytes) Dynamisch (niveau) Statisch (Niveau) Cache hint
HTML 1024 Br 3–4 / Gz 5–6 Br 9-11 (voorgecomprimeerd) Lange TTL voor hashnamen
CSS/JS 1024 Zelden dynamisch Br 9-11 (voorgecomprimeerd) onveranderlijk, varianten per hash
JSON (API's) 512-1024 Br 3–4 / Gz 5–6 niet gebruikelijk Houd de koptekst consistent
SVG 1024 Zelden dynamisch Br 9–11 Verzoeken voor testbereik
Lettertypen (WOFF2) geen geen geen Niet verder samendrukken
Afbeeldingen (PNG/JPEG/WEBP) geen geen geen Afzonderlijke optimalisatie
PDF geen geen geen Codering vermijden

Zstd in context: wanneer zinvol, wanneer niet

Ik beoordeel Zstd onafhankelijk omdat het een uitstekende Doorvoersnelheden met goede compressie. In de browseromgeving is de ondersteuning echter heterogeen, daarom rol ik Zstd meestal niet uit als de primaire codering voor eindgebruikers. Tussen interne diensten of op de CDN backbone route kan Zstd erg nuttig zijn om Origin CDN verkeer efficiënt te houden. Aan de rand blijf ik bij Brotli (voor tekst) en Gzip als fallback totdat een breed ondersteunde klantenbasis ervoor zorgt dat varianten correct worden onderhandeld. In Caddy laat ik Zstd optioneel actief, maar geef ik prioriteit aan de Onderhandeling Brotli vóór Gzip om compatibiliteit en prestaties in balans te brengen.

Bereik aanvragen, downloads en voorgecomprimeerde bestanden

Grote downloads (bijv. PDF's, CSV's) controleer ik apart. Voor binaire gegevens schakel ik meestal inhoudscodering uit en lever ik identiteit (identiteit) zodat bereikverzoeken goed werken en hervattingsdownloads stabiel blijven. Voor statische tekstbestanden met .br/.gz-varianten zorg ik ervoor dat de server de juiste variant selecteert afhankelijk van het clientverzoek en dat de inhoudslengte, inhoudscodering en ETag consistent zijn. Voor gedeeltelijke verzoeken naar gecomprimeerde varianten, bytebereiken voor de gecomprimeerd lengte - als de stack dit niet robuust afhandelt, lever ik de ongecomprimeerde versie voor bereikverzoeken. Dit beperkt randgevallen en voorkomt onjuiste herstarts.

Beveiliging: compressie en datalekken

Ik houd rekening met compressiegerelateerde nevenkanalen zoals BREACH. Als reacties geheim-afhankelijke inhoud (tokens, sessie-ID's) weergeven in de buurt van ingangen die door de aanvaller kunnen worden gecontroleerd, schakel ik selectief compressie uit of ontkoppel ik de geheimen (padding, scheiding in afzonderlijke ongecomprimeerde velden). Voor aanmeldings- en betaalpaden is het zinvol om compressie uit te schakelen met behulp van headers of regels. Cookies met ingestelde cookie headers zijn niet kritisch, wat belangrijk is, is de Antwoord-payload. Daarom heb ik filters klaarstaan die gericht zijn op het pad, MIME of bepaalde sjablonen om gemakkelijk heuristieken af te dwingen.

CDN- en proxy-ketens: één compressie per hop

Ik definieer duidelijk de hop waarbij compressie plaatsvindt: Ofwel bij de Rand (CDN) of op de Origin, niet allebei. Als het CDN comprimeert, laat ik contentcodering op de Origin weg en stuur ik Vary: Accept codering mee, zodat de Edge de juiste varianten bouwt. Als de Origin voorgecomprimeerde assets (.br/.gz) moet aanleveren, configureer ik de Edge om deze bestanden naar het CDN te sturen. Transparant en transformeert het niet opnieuw. Als ik transformaties door tussenliggende proxies strikt wil voorkomen (bijv. voor compliance), stel ik Cache-Control: no-transform in - dan plan ik compressie specifiek op de origin. Voor het debuggen noteer ik welke hop de Compressie en houd de metriek apart per hop.

Streaming, SSE, gRPC en WebSockets

Voor server-sent events (SSE) en vergelijkbare streams vermijd ik hoge niveaus en groot buffer; anders neemt de latentie merkbaar toe. Ik gebruik kleine blokken, frequente flushes en meer uitgeschakelde compressie als interactiviteit prioriteit heeft. gRPC gebruikt zijn eigen berichtcompressie en draait via HTTP/2 - hier vermijd ik extra HTTP inhoudscodering om duplicatie te voorkomen. Hetzelfde geldt voor WebSockets: per-bericht deflate kan nuttig zijn, maar ik schakel het alleen in voor echt tekstzware kanalen en observeer de CPU-effect precies.

Toepassingsserver: Instellingen voor app-laag specifiek instellen

Ik geef er de voorkeur aan om de drempels in de edge/reverse proxy te regelen, maar wanneer raamwerken comprimeren, stel ik consistente waarden in zodat niets elkaar tegenwerkt.

  • Node.js/ExpressIk stel een drempel in van 1024 bytes en matige niveaus. De statische handler serveert voorgecomprimeerde statische activa direct, ik comprimeer alleen dynamische routes voor tekst-MIME's.
  • Ga naarIk selecteer een duidelijke toegestane lijst van MIME's voor elke handler en sla compressie onder 1 KB over. Voor lange streams houd ik de write flushes klein om de eerste paint niet te overbelasten. vertraging.
  • Java/TomcatIk gebruik compressionMinSize 1024 en onderhoud de MIME-lijst expliciet; binaire types worden weggelaten.

Tomcat Voorbeeld (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" />

Belangrijk: Als een upstream proxy (Nginx, Caddy) al comprimeert, schakel ik app layer compressie uit om Dubbel werk en laat slechts één laag de verantwoordelijkheid dragen.

Adaptieve drempels en belastingsregeling

Ik denk in termen van beleid in plaats van starre waarden. Onder hoge CPU-belasting til ik de Drempel tijdelijk (bijv. van 1024 naar 2048 bytes) of verlaag het Brotli-niveau (bijv. 4 naar 2) voor dynamische reacties. Als de belasting daalt, verhoog ik de waarden weer. Dit kan geregeld worden via een feature flag, Env variabelen of een simpele reload. Op nodes met weinig CPU, reserveer ik compressie voor de belangrijkste MIME's (HTML/JSON), terwijl CSS/JS bijna uitsluitend voorgecomprimeerd uit de opslag/CDN komt. Dit Prioritering houdt TTFB stabiel in plaats van in pieken te vervallen.

Test draaiboek: snelle verificatie

Ik controleer het effect met een paar reproduceerbare stappen:

  • Onderhandeling: curl -I -H „Accept-Encoding: br“ https://example.com - controleer Content-Encoding, Vary en Content-Length.
  • Terugvalcurl -I -H „Accept-Encoding: gzip“ - verwachtte gzip? ETag anders dan Brotli?
  • Zonder compressiecurl -I -H „Accept-Encoding: identity“ - Vergelijk grootteverschil en TTFB.
  • Bereikcurl -I -H „Range: bytes=0-1023“ - accepteert de server subranges correct en klopt Content-Range?
  • DevToolsVergelijk grootte „Over het netwerk“ vs. „Grootte van bron“ om werkelijke grootte te bepalen Besparingen om te zien.

Kort samengevat

Stel de drempel in op 1024 bytes als snel startpunt, controleer TTFB en CPU en verfijn je instellingen met kleine Aanpassingen na. Gebruik Brotli 3-4 voor dynamische inhoud en 9-11 voor voorgecomprimeerde middelen, houd Gzip 5-6 als fallback. Comprimeer alleen tekst-MIME's en lever voorgecomprimeerde bestanden direct aan om bouwmaterialen licht en duurzaam te houden. Besteed aandacht aan Vary: Accept-Encoding, Content-Encoding en encoding-specifieke ETags zodat caches correct werken. Met goed ingestelde HTTP-compressiedrempels kun je de levering merkbaar versnellen zonder de machine te belasten met onnodig rekenwerk. blok.

Huidige artikelen