{"id":19272,"date":"2026-05-12T18:43:17","date_gmt":"2026-05-12T16:43:17","guid":{"rendered":"https:\/\/webhosting.de\/http-compression-thresholds-konfiguration-webhosting-cachetuning\/"},"modified":"2026-05-12T18:43:17","modified_gmt":"2026-05-12T16:43:17","slug":"http-komprimeringstaerskler-konfiguration-webhosting-cache-tuning","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/http-compression-thresholds-konfiguration-webhosting-cachetuning\/","title":{"rendered":"HTTP-komprimeringst\u00e6rskler: Optimale konfigurationer til webhosting"},"content":{"rendered":"<p>HTTP-komprimeringst\u00e6rskler bestemmer den st\u00f8rrelse, hvormed din server komprimerer indhold, og styrer dermed direkte TTFB, CPU-belastning og b\u00e5ndbredde. I denne vejledning vil jeg vise dig specifikke t\u00e6rskler, niveauer og headerindstillinger for hurtig levering samt en klar adskillelse mellem dynamisk og statisk komprimering. <strong>Kompression<\/strong>.<\/p>\n\n<h2>Centrale punkter<\/h2>\n\n<p>Jeg opsummerer de vigtigste justeringer f\u00f8rst, s\u00e5 du kan komme i gang p\u00e5 en m\u00e5lrettet m\u00e5de og undg\u00e5 at spilde un\u00f8dvendige CPU-cyklusser. Jeg er afh\u00e6ngig af klare t\u00e6rskler, passende niveauer og rene headere, s\u00e5 browsere, proxyer og CDN'er arbejder korrekt sammen. Jeg skelner mellem dynamiske svar og build-aktiver og holder komprimering pr. hop strengt under kontrol. Jeg minimerer TTFB med moderate niveauer af runtime-komprimering og f\u00e5r maksimal hastighed fra pr\u00e6-komprimerede filer. Jeg tjekker regelm\u00e6ssigt m\u00e5linger og justerer t\u00e6rskler til belastning, filmix og latenstid i den virkelige verden, s\u00e5 din ops\u00e6tning bliver m\u00e6rkbart mere effektiv. <strong>hurtigere<\/strong> vil.<\/p>\n\n<ul>\n  <li><strong>T\u00e6rskel<\/strong> 512-1024 B, standard 1024 B<\/li>\n  <li><strong>Br\u00f8dpind<\/strong> 3-4 dynamisk, 9-11 statisk<\/li>\n  <li><strong>Gzip<\/strong> 5-6 som reserve<\/li>\n  <li><strong>MIME<\/strong> Kun tekstressourcer<\/li>\n  <li><strong>Varierer<\/strong> og ETag pr. kodning<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/05\/serverraum-kompression-8342.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Hvad er HTTP-komprimeringst\u00e6rskler?<\/h2>\n\n<p>En t\u00e6rskel bestemmer den st\u00f8rrelse, over hvilken et svar komprimeres, og forhindrer, at header-overhead kunstigt puster sm\u00e5 filer op; det er netop her, at <strong>Break-even<\/strong>-overvejelser. Med meget sm\u00e5 svar kan indholdskodning \u00f8ge nyttelasten og koste CPU p\u00e5 samme tid. Derfor s\u00e6tter jeg normalt en nedre gr\u00e6nse p\u00e5 1024 bytes, eller 512 bytes for h\u00f8jfrekvente API'er med mange sm\u00e5 svar. Mindre t\u00e6rskler \u00f8ger komprimeringsgraden, men de driver TTFB og CPU, n\u00e5r dynamisk indhold varierer meget. St\u00f8rre t\u00e6rskler sparer computertid, men risikerer spildt potentiale med mellemstore HTML-, CSS- eller JSON-filer, der er af god kvalitet. <strong>Reduktion<\/strong> fordel.<\/p>\n\n<h2>Brotli vs. Gzip: Valg og niveauer<\/h2>\n\n<p>Brotli opn\u00e5r ofte 15-21 procent bedre hastigheder end Gzip for tekstressourcer, men koster mere CPU pr. anmodning, hvilket jeg tager h\u00f8jde for ved dynamiske svar og med moderate niveauer. <strong>pude<\/strong>. Til runtime-komprimering bruger jeg Brotli niveau 3-4, til f\u00e6rdigpakkede aktiver niveau 9-11. Til \u00e6ldre klienter eller indhold, der \u00e6ndrer sig meget, bruger jeg Gzip niveau 5-6. HTTP\/2 og HTTP\/3 drager fordel af god komprimering, s\u00e5 l\u00e6nge serverbufferne og flush-punkterne er indstillet korrekt, og ingen str\u00f8m g\u00e5r i st\u00e5. Hvis du vil lave en dybere sammenligning, kan du finde mere information i min <a href=\"https:\/\/webhosting.de\/da\/gzip-vs-brotli-sammenligning-hosting-optimus\/\">Sammenligning Gzip vs. Brotli<\/a> yderligere praktiske v\u00e6rdier og overvejelser, der g\u00f8r valget i den daglige hosting <strong>lette<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/05\/webhost-konf-2837.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>S\u00e6t t\u00e6rskler: Beskyttelseslinjer og break-even<\/h2>\n\n<p>Jeg starter med 1024 bytes som en grundl\u00e6ggende gr\u00e6nse, fordi header-overhead s\u00e5 klart overkompenseres, og CPU-forbruget forbliver rimeligt, is\u00e6r med HTML og JSON, som er meget forskellige. <strong>kondensere<\/strong> g\u00e5. Med netv\u00e6rk med meget lav latenstid og mange minimale API-svar kan 512 bytes v\u00e6re nyttigt. Komprimering kan sj\u00e6ldent betale sig under 512 bytes, fordi administrationsomkostningerne ofte overstiger reduktionen af nyttelasten. I tilf\u00e6lde af st\u00e6rkt belastede maskiner \u00f8ger jeg midlertidigt t\u00e6rsklen, indtil CPU-reservoirerne igen har buffere. Denne gradvise justering holder TTFB lav og bevarer <strong>Stabilitet<\/strong> af det samlede system.<\/p>\n\n<h2>Komprim\u00e9r MIME-typer specifikt<\/h2>\n\n<p>Jeg komprimerer kun tekst-MIME'er som text\/html, text\/css, application\/javascript, application\/json og image\/svg+xml, fordi de kan bruges af redundans\u00e5rsager. <strong>Gevinster<\/strong> tr\u00e6kke. Jeg lader bin\u00e6rt indhold som image\/*, application\/pdf eller font\/woff2 v\u00e6re uber\u00f8rt, da effekten er lille eller negativ. Til skrifttyper bruger jeg WOFF2 direkte, fordi den allerede koder effektivt, og yderligere komprimering ikke er til megen nytte. Jeg opretholder eksplicitte tilladelseslister og undg\u00e5r wildcards, s\u00e5 ingen bin\u00e6re filer ved et uheld ender i encoderen. P\u00e5 den m\u00e5de holder jeg komprimeringsk\u00e6den ren og forhindrer <strong>Korruption<\/strong> p\u00e5 grund af fejlklassificering.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/05\/http-compression-thresholds-optimal-7234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Statisk vs. dynamisk: ren adskillelse<\/h2>\n\n<p>Jeg pakker statiske aktiver i byggeprocessen eller p\u00e5 CDN-kanten p\u00e5 forh\u00e5nd som .br og .gz og lader serveren bruge disse varianter direkte. <strong>levere<\/strong>. Ved dynamiske svar indstiller jeg moderate niveauer og holder bufferne sm\u00e5 nok til, at den f\u00f8rste byteblok flyder hurtigt. Det er vigtigt kun at komprimere \u00e9t hop i proxy-k\u00e6der, s\u00e5 der ikke sker dobbeltkomprimering. Jeg kan sl\u00e5 komprimering fra p\u00e5 Origin, hvis CDN'et allerede har gjort det og adskiller det korrekt via Vary. Denne adskillelse sparer CPU og sikrer konstant <strong>Svartider<\/strong> selv under belastning.<\/p>\n\n<h2>Header management og caching<\/h2>\n\n<p>Jeg sender altid Vary: Accept-Encoding, s\u00e5 cachen kan skelne korrekt mellem varianter, og der ikke er nogen fejl, som g\u00f8r brugerne langsommere eller forfalsker aktiverne; denne header er <strong>afg\u00f8rende<\/strong>. For statiske filer indstiller jeg indholdskodning (br\/gzip) plus indholdsl\u00e6ngde, mens dynamiske streams ofte k\u00f8rer med overf\u00f8rselskodning: chunked. ETags skal v\u00e6re kodningsspecifikke, ellers vil cachen levere forkerte versioner. Derudover s\u00e6tter jeg lange cache-TTL'er for pr\u00e6-komprimerede aktiver og sikrer dem med cachekontrol: offentlig, uforanderlig, hvis filhashes er i navnet. Jeg giver et kompakt udgangspunkt her: <a href=\"https:\/\/webhosting.de\/da\/http-komprimering-konfiguration-ydeevneforbedring-optimeret\/\">Konfiguration af HTTP-komprimering<\/a>, der viser dig de vigtigste byggesten i <strong>Sekvens<\/strong> viser.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/05\/http_komprimierung_tech_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>HTTP\/2 og HTTP\/3: Flush og buffer<\/h2>\n\n<p>Med HTTP\/2 og HTTP\/3 er jeg opm\u00e6rksom p\u00e5 tidlige flush-punkter, s\u00e5 kritisk HTML og CSS ikke forsinker starten p\u00e5 gengivelsen. <strong>forsinkelse<\/strong>. For store buffere kan g\u00f8re multiplexing langsommere, fordi en str\u00f8m dominerer planl\u00e6gningen, og andet indhold venter. Jeg holder de f\u00f8rste komprimeringsblokke sm\u00e5 og sender hurtigt, og s\u00e5 \u00f8ger jeg blokst\u00f8rrelsen for lange filer. Brotli viser gode hastigheder med moderat overhead, s\u00e5 l\u00e6nge niveau 3-4 bruges til dynamiske svar. Det holder interaktiviteten h\u00f8j, mens store bundter er effektive. <strong>krympe<\/strong>.<\/p>\n\n<h2>\u00d8velse: Apache, Nginx, Caddy<\/h2>\n\n<p>Jeg starter med moderate niveauer og en t\u00e6rskel p\u00e5 1024 bytes og tjekker derefter systematisk TTFB og CPU i stedet for blindt at s\u00e6tte maksimale hastigheder. <strong>h\u00e5ndh\u00e6ve<\/strong>. For Apache aktiverer jeg mod_deflate eller mod_brotli og definerer kun de \u00f8nskede MIME-typer. I Nginx s\u00e6tter jeg gzip_min_length til 1024 og Brotli til on og kombinerer det med brotli_static til forkomprimerede filer. Caddy tilbyder enkle switches med kodningerne gzip zstd br; jeg h\u00e5ndterer dynamiske stier med lave niveauer separat. Erfaringsm\u00e6ssigt er det v\u00e6rd at tage et kig p\u00e5 <a href=\"https:\/\/webhosting.de\/da\/komprimeringsniveau-cpu-belastning-gzip-brotli-optimering-datastrom\/\">CPU-belastning og komprimeringsniveau<\/a>, fordi kombinationen af andelen af dynamiske svar og antallet af kerner ofte overskrider gr\u00e6nsen. <strong>s\u00e6t<\/strong>.<\/p>\n\n<p><strong>Apache<\/strong> Eksempel (mod_deflate\/mod_brotli):<\/p>\n<pre><code>.\n AddOutputFilterByType DEFLATE text\/html text\/css application\/javascript application\/json image\/svg+xml\n S\u00e6tOutputFilter DEFLATE\n DeflateCompressionLevel 6\n DeflateBufferSize 64k\n.\n\n\n AddOutputFilterByType BROTLI_COMPRESS text\/html text\/css application\/javascript application\/json image\/svg+xml\n BrotliCompressionQuality 4\n BrotliWindowSize 22\n.<\/code><\/pre>\n\n<p><strong>Nginx<\/strong> Et eksempel:<\/p>\n<pre><code>gzip p\u00e5;\ngzip_min_length 1024;\ngzip_types text\/plain text\/css application\/json application\/javascript image\/svg+xml;\ngzip_comp_level 5;\n\nbrotli p\u00e5;\nbrotli_comp_level 4;\nbrotli_static on;\nbrotli_types text\/plain text\/css application\/json application\/javascript image\/svg+xml;<\/code><\/pre>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/05\/http-kompressionsschwellen-5432.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Overv\u00e5gning og fejlfinding<\/h2>\n\n<p>Jeg m\u00e5ler TTFB, CPU-brug pr. medarbejder og overf\u00f8rselsst\u00f8rrelse pr. type, s\u00e5 jeg kan se, hvor komprimering hj\u00e6lper, og hvor det er n\u00f8dvendigt. <strong>skader<\/strong>. Hvis TTFB stiger efter aktivering, s\u00e6nker jeg niveauet eller h\u00e6ver t\u00e6rsklen. Hvis der er m\u00e6rkelige effekter, tjekker jeg f\u00f8rst for dobbeltkomprimering, manglende Vary-headere eller forkert genkendte MIME-typer. Jeg kigger ogs\u00e5 p\u00e5 CDN- og WAF-politikker, fordi et andet hop med komprimering flytter belastningen og ofte forv\u00e6rrer tiden til den f\u00f8rste byte. V\u00e6rkt\u00f8jer som WebPageTest og Browser-DevTools er tilstr\u00e6kkelige til en indledende kontrol. <strong>Revision<\/strong> fuldst\u00e6ndig.<\/p>\n\n<h2>M\u00e5lepunkter og anbefalede v\u00e6rdier<\/h2>\n\n<p>Jeg holder mig til nogle f\u00e5, klare parametre, s\u00e5 konfigurationen forbliver overskuelig og stadig opn\u00e5r et h\u00f8jt kvalitetsniveau. <strong>Effekt<\/strong> viser. F\u00f8lgende tabel opsummerer nyttige t\u00e6rskler, niveauer og cachelagringsinstruktioner. Den d\u00e6kker typiske webstakke med HTML, CSS, JS, JSON, SVG og skrifttyper. Juster t\u00e6rsklen afh\u00e6ngigt af belastningen, CPU-reservoiret og andelen af dynamiske svar. Start konservativt, m\u00e5l, og flyt iterativt skyderne i sm\u00e5 trin. <strong>Trin<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Ressource<\/th>\n      <th>T\u00e6rskelv\u00e6rdi (bytes)<\/th>\n      <th>Dynamisk (niveau)<\/th>\n      <th>Statisk (niveau)<\/th>\n      <th>Hint til cachen<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>HTML<\/td>\n      <td>1024<\/td>\n      <td>Br 3\u20134 \/ Gz 5\u20136<\/td>\n      <td>Br 9-11 (forkomprimeret)<\/td>\n      <td>Lang TTL for hash-navne<\/td>\n    <\/tr>\n    <tr>\n      <td>CSS\/JS<\/td>\n      <td>1024<\/td>\n      <td>Sj\u00e6ldent dynamisk<\/td>\n      <td>Br 9-11 (forkomprimeret)<\/td>\n      <td>uforanderlig, varianter pr. hash<\/td>\n    <\/tr>\n    <tr>\n      <td>JSON (API'er)<\/td>\n      <td>512-1024<\/td>\n      <td>Br 3\u20134 \/ Gz 5\u20136<\/td>\n      <td>ikke almindeligt<\/td>\n      <td>Hold overskriften konsistent<\/td>\n    <\/tr>\n    <tr>\n      <td>SVG<\/td>\n      <td>1024<\/td>\n      <td>Sj\u00e6ldent dynamisk<\/td>\n      <td>Br 9\u201311<\/td>\n      <td>Anmodninger om testomr\u00e5de<\/td>\n    <\/tr>\n    <tr>\n      <td>Skrifttyper (WOFF2)<\/td>\n      <td>ingen<\/td>\n      <td>ingen<\/td>\n      <td>ingen<\/td>\n      <td>Tryk ikke yderligere sammen<\/td>\n    <\/tr>\n    <tr>\n      <td>Billeder (PNG\/JPEG\/WEBP)<\/td>\n      <td>ingen<\/td>\n      <td>ingen<\/td>\n      <td>ingen<\/td>\n      <td>Separat optimering<\/td>\n    <\/tr>\n    <tr>\n      <td>PDF<\/td>\n      <td>ingen<\/td>\n      <td>ingen<\/td>\n      <td>ingen<\/td>\n      <td>Undg\u00e5 kodning<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Zstd i kontekst: hvorn\u00e5r det giver mening, hvorn\u00e5r ikke<\/h2>\n\n<p>Jeg vurderer Zstd uafh\u00e6ngigt, fordi det har fremragende <strong>Gennemstr\u00f8mningshastigheder<\/strong> med god komprimering. I browsermilj\u00f8et er underst\u00f8ttelsen dog uensartet, og derfor udruller jeg normalt ikke Zstd som den prim\u00e6re slutbrugerkodning. Mellem interne tjenester eller p\u00e5 CDN-backbone-ruten kan Zstd v\u00e6re meget nyttig til at holde Origin CDN-trafikken effektiv. P\u00e5 kanten holder jeg mig til Brotli (til tekst) og Gzip som reserve, indtil en bredt underst\u00f8ttet klientbase sikrer, at varianterne forhandles korrekt. I Caddy lader jeg Zstd v\u00e6re valgfrit aktiv, men prioriterer <strong>Forhandling<\/strong> Brotli f\u00f8r Gzip for at skabe balance mellem kompatibilitet og ydeevne.<\/p>\n\n<h2>Range requests, downloads og pr\u00e6-komprimerede filer<\/h2>\n\n<p>Jeg tjekker store downloads (f.eks. PDF'er, CSV'er) separat. For bin\u00e6re data sl\u00e5r jeg normalt indholdskodning fra og leverer identitet (<strong>identitet<\/strong>), s\u00e5 anmodninger om r\u00e6kkevidde fungerer korrekt, og genoptage downloads forbliver stabile. For statiske tekstfiler med .br\/.gz-varianter sikrer jeg, at serveren v\u00e6lger den korrekte variant afh\u00e6ngigt af klientens anmodning, og at indholdsl\u00e6ngde, indholdskodning og ETag er konsistente. For delvise anmodninger om komprimerede varianter, byte-intervaller for <strong>komprimeret<\/strong> l\u00e6ngde - hvis stakken ikke h\u00e5ndterer dette robust, leverer jeg den ukomprimerede version til range-anmodninger. Det afb\u00f8der edge cases og forhindrer forkerte genstarter.<\/p>\n\n<h2>Sikkerhed: komprimering og datal\u00e6kager<\/h2>\n\n<p>Jeg tager h\u00f8jde for kompressionsrelaterede sidekanaler som f.eks. <strong>BRUD<\/strong>. Hvis svar afspejler hemmelighedsafh\u00e6ngigt indhold (tokens, sessions-ID'er) t\u00e6t p\u00e5 input, der kan kontrolleres af angriberen, deaktiverer jeg selektivt komprimering eller afkobler hemmelighederne (padding, adskillelse i separate ukomprimerede felter). For login- og betalingsstier giver det mening at sl\u00e5 komprimering fra ved hj\u00e6lp af overskrifter eller regler. Cookies med indstillede cookie-overskrifter er ikke kritiske, det, der er vigtigt, er <strong>Svar<\/strong>-payload. Jeg har derfor filtre klar, der retter sig mod stien, MIME eller bestemte skabeloner for nemt at kunne h\u00e5ndh\u00e6ve heuristik.<\/p>\n\n<h2>CDN- og proxy-k\u00e6der: \u00e9n komprimering pr. hop<\/h2>\n\n<p>Jeg definerer klart det hop, hvor komprimeringen finder sted: Enten ved <strong>Kant<\/strong> (CDN) eller p\u00e5 Origin, ikke begge dele. Hvis CDN'et komprimerer, udelader jeg indholdskodning p\u00e5 Origin og sender Vary: Accept-kodning, s\u00e5 Edge bygger korrekte varianter. Hvis Origin skal levere pr\u00e6-komprimerede aktiver (.br\/.gz), konfigurerer jeg Edge til at sende disse filer til CDN'et. <em>Gennemsigtig<\/em> og transformerer det ikke igen. Hvis jeg strengt vil forhindre transformationer af mellemliggende proxyer (f.eks. af hensyn til compliance), indstiller jeg Cache-Control: no-transform - s\u00e5 planl\u00e6gger jeg komprimering specifikt ved oprindelsen. Til fejlfinding noterer jeg, hvilket hop <strong>Kompression<\/strong> og holde m\u00e5lingerne adskilt pr. hop.<\/p>\n\n<h2>Streaming, SSE, gRPC og WebSockets<\/h2>\n\n<p>For server-sendte begivenheder (SSE) og lignende str\u00f8mme undg\u00e5r jeg h\u00f8je niveauer og <strong>stor<\/strong> buffer; ellers \u00f8ges ventetiden m\u00e6rkbart. Jeg bruger sm\u00e5 blokke, hyppige flushes og mere deaktiveret komprimering, hvis interaktivitet har prioritet. gRPC bruger sin egen meddelelseskomprimering og k\u00f8rer via HTTP\/2 - her undg\u00e5r jeg yderligere HTTP-indholdskodning for at forhindre duplikering. Det samme g\u00e6lder for WebSockets: deflate pr. besked kan v\u00e6re nyttigt, men jeg sl\u00e5r det kun til for virkelig teksttunge kanaler og observerer <strong>CPU<\/strong>-effekt pr\u00e6cis.<\/p>\n\n<h2>Applikationsserver: Indstil app-lagets indstillinger specifikt<\/h2>\n\n<p>Jeg foretr\u00e6kker at styre t\u00e6rsklerne i edge\/reverse-proxyen, men n\u00e5r frameworks komprimeres, indstiller jeg ensartede v\u00e6rdier, s\u00e5 intet modarbejder hinanden.<\/p>\n\n<ul>\n  <li><strong>Node.js\/Express<\/strong>Jeg s\u00e6tter en t\u00e6rskel p\u00e5 1024 bytes og moderate niveauer. Den statiske handler serverer forkomprimerede statiske aktiver direkte, jeg komprimerer kun dynamiske ruter til tekst-MIME'er.<\/li>\n  <li><strong>G\u00e5<\/strong>Jeg v\u00e6lger en klar liste over tilladte MIME'er for hver handler og springer komprimering over under 1 KB. For lange streams holder jeg skriveflushes sm\u00e5 for ikke at overbelaste den f\u00f8rste maling. <strong>forsinkelse<\/strong>.<\/li>\n  <li><strong>Java\/Tomcat<\/strong>Jeg bruger compressionMinSize 1024 og vedligeholder MIME-listen eksplicit; bin\u00e6re typer er udeladt.<\/li>\n<\/ul>\n\n<p><strong>Tomcat<\/strong> Eksempel (server.xml Connector):<\/p>\n<pre><code>.<\/code><\/pre>\n\n<p>Vigtigt: Hvis en upstream-proxy (Nginx, Caddy) allerede komprimerer, deaktiverer jeg applagskomprimering for at <strong>Dobbeltarbejde<\/strong> og kun lade \u00e9t lag b\u00e6re ansvaret.<\/p>\n\n<h2>Adaptive t\u00e6rskler og belastningskontrol<\/h2>\n\n<p>Jeg t\u00e6nker i politikker i stedet for stive v\u00e6rdier. Under h\u00f8j CPU-belastning l\u00f8fter jeg <strong>T\u00e6rskel<\/strong> midlertidigt (f.eks. fra 1024 til 2048 bytes) eller s\u00e6nke Brotli-niveauet (f.eks. 4 til 2) for dynamiske svar. Hvis belastningen falder, \u00f8ger jeg v\u00e6rdierne igen. Dette kan styres via et funktionsflag, Env-variabler eller en simpel genindl\u00e6sning. P\u00e5 noder med lidt CPU reserverer jeg komprimering til de vigtigste MIME'er (HTML\/JSON), mens CSS\/JS n\u00e6sten udelukkende kommer pr\u00e6-komprimeret fra storage\/CDN. Dette <strong>Prioritering<\/strong> holder TTFB stabil i stedet for at tippe over i toppe.<\/p>\n\n<h2>Test playbook: hurtig verifikation<\/h2>\n\n<p>Jeg tjekker effekten med et par reproducerbare trin:<\/p>\n<ul>\n  <li><strong>Forhandling<\/strong>: curl -I -H \u201eAccept-Encoding: br\u201c https:\/\/example.com - tjek Content-Encoding, Vary og Content-Length.<\/li>\n  <li><strong>Tilbagefald<\/strong>: curl -I -H \u201eAccept-Encoding: gzip\u201c - forventet gzip? ETag forskellig fra Brotli?<\/li>\n  <li><strong>Uden kompression<\/strong>curl -I -H \u201eAccept-Encoding: identity\u201c - Sammenlign st\u00f8rrelsesforskel og TTFB.<\/li>\n  <li><strong>R\u00e6kkevidde<\/strong>: curl -I -H \u201eRange: bytes=0-1023\u201c - accepterer serveren subranges korrekt, og passer Content-Range?<\/li>\n  <li><strong>DevTools<\/strong>Sammenlign st\u00f8rrelse \u201eOver netv\u00e6rket\u201c vs. \u201eRessourcest\u00f8rrelse\u201c for at bestemme den reelle <strong>Besparelser<\/strong> at se.<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/05\/serverraum-komprimierung-4821.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Kort opsummeret<\/h2>\n\n<p>S\u00e6t t\u00e6rsklen til 1024 bytes som et hurtigt udgangspunkt, tjek TTFB og CPU, og finjuster dine indstillinger med sm\u00e5 <strong>Justeringer<\/strong> efter. Brug Brotli 3-4 til dynamisk indhold og 9-11 til pr\u00e6-komprimerede aktiver, behold Gzip 5-6 som en reserve. Komprimer kun tekst-MIME'er, og lever pr\u00e6-komprimerede filer direkte for at holde build-aktiver lette og holdbare. V\u00e6r opm\u00e6rksom p\u00e5 Vary: Accept-Encoding, Content-Encoding og kodningsspecifikke ETags, s\u00e5 caches fungerer korrekt. Med korrekt indstillede HTTP-komprimeringst\u00e6rskler kan du m\u00e6rkbart fremskynde leveringen uden at belaste maskinen med un\u00f8dvendigt computerarbejde. <strong>blok<\/strong>.<\/p>","protected":false},"excerpt":{"rendered":"<p>Korrekt indstilling af HTTP-komprimeringst\u00e6rskler: gzip-t\u00e6rskeltuning, brotli-optimering og hosting af webkomprimering for topydelse.<\/p>","protected":false},"author":1,"featured_media":19265,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-19272","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-plesk-webserver-plesk-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"87","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"HTTP Compression Thresholds","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"19265","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/19272","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/comments?post=19272"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/19272\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/19265"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=19272"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=19272"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=19272"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}