{"id":20738,"date":"2026-08-17T15:05:56","date_gmt":"2026-08-17T13:05:56","guid":{"rendered":"https:\/\/webhosting.de\/brotli-compression-performance-cpu-verbrauch-technik\/"},"modified":"2026-08-17T15:05:56","modified_gmt":"2026-08-17T13:05:56","slug":"brotli-komprimering-ydeevne-cpu-forbrug-teknik","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/brotli-compression-performance-cpu-verbrauch-technik\/","title":{"rendered":"Brotli-komprimeringsniveau: Ydeevne eller CPU-forbrug?"},"content":{"rendered":"<p><strong>Brotli-komprimering<\/strong> tvinger mig til at afveje klart mellem mindre overf\u00f8rselsst\u00f8rrelse og ekstra CPU-forbrug. Jeg viser, hvordan jeg for dynamiske svar oftest opn\u00e5r den bedste balance mellem tid og st\u00f8rrelse med niveau 4\u20136, og hvorn\u00e5r niveau 9\u201311 giver reelle fordele ved forh\u00e5ndspakkede assets.<\/p>\n\n<h2>Centrale punkter<\/h2>\n\n<p>F\u00f8lgende punkter giver mig en kortfattet oversigt over planl\u00e6gning og drift:<\/p>\n<ul>\n  <li><strong>Valg af niveau<\/strong>: H\u00f8jere niveauer sparer bytes, men kr\u00e6ver mere CPU-kraft og tid.<\/li>\n  <li><strong>Dynamik<\/strong>: Ved live-komprimering giver niveau 4\u20136 ofte den bedste balance.<\/li>\n  <li><strong>Statisk<\/strong>: Forh\u00e5ndspakkede assets drager fordel af niveau 9\u201311.<\/li>\n  <li><strong>Sammenligning<\/strong>: Brotli komprimerer teksten ofte mere, mens Gzip komprimerer hurtigere.<\/li>\n  <li><strong>Betjening<\/strong>: M\u00e5lev\u00e6rdier som TTFB, CPU-belastning og fejlprocent er afg\u00f8rende for valget.<\/li>\n<\/ul>\n\n<h2>Hvorfor Brotli-niveauet er vigtigt<\/h2>\n\n<p>Det bestemmer jeg <strong>Kompressionsniveau<\/strong> ikke ud fra mavefornemmelse, men ud fra indsats og udbytte. For hvert trin stiger regnearbejdet, mens den ekstra besparelse i byte fra et bestemt punkt kun er minimal. Det er netop her, fordelen vendes: En fil, der er et par procentpoint mindre, retf\u00e6rdigg\u00f8r ikke altid mere latenstid og CPU-belastning. Is\u00e6r ved live-komprimering bremser et for h\u00f8jt niveau responstiden, selvom dataoverf\u00f8rslen kun falder minimalt. Derfor bruger jeg m\u00e5linger og ser p\u00e5 latenstid, beregningstid og gennemstr\u00f8mning, f\u00f8r jeg fastl\u00e6gger niveauet.<\/p>\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\/08\/brotli-kompression-performance-4912.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Hvorn\u00e5r jeg bevidst undlader at komprimere<\/h2>\n\n<p>Ikke hver eneste byte sparer tid p\u00e5 en meningsfuld m\u00e5de. Meget sm\u00e5 svar (f.eks. under 1\u20132 KB) og allerede komprimerede bin\u00e6re formater giver n\u00e6sten ingen gevinst, men belaster CPU\u2019en. Derfor indstiller jeg <strong>T\u00e6rskelv\u00e6rdier<\/strong> pr. MIME-type og rute:<\/p>\n<ul>\n  <li>Sm\u00e5 tekstuddrag eller 204\/304-svar: leveres uden komprimering.<\/li>\n  <li>Billeder, videoer, PDF-filer, arkiver: udelukkes generelt (ofte allerede komprimeret internt).<\/li>\n  <li>Vigtige svar vedr\u00f8rende streaming: hellere med Gzip eller slet ikke, for at undg\u00e5 spidsbelastninger i latenstiden.<\/li>\n<\/ul>\n<p>Ved at indf\u00f8re klare undtagelser aflaster jeg workerne og holder P95\/P99-TTFB stabil.<\/p>\n\n<h2>Encoder-parametre, der g\u00f8r hele forskellen<\/h2>\n\n<p>Ud over kvalitetsniveauet har f\u00f8lgende faktorer indflydelse p\u00e5 <strong>Encoder-indstillinger<\/strong> Tid og fornuft m\u00e6rkes:<\/p>\n<ul>\n  <li><strong>Tilstand<\/strong> (generic, text, font): For HTML\/CSS\/JS angiver jeg \u201etext\u201c, og for skrifttyper \u201efont\u201c. Det hj\u00e6lper koderen med bedre at genkende m\u00f8nstre.<\/li>\n  <li><strong>Vinduesst\u00f8rrelse (lgwin)<\/strong>: St\u00f8rre vinduer forbedrer ofte l\u00e6seoplevelsen ved lange tekster, men belaster RAM og CPU. Af praktiske \u00e5rsager holder jeg mig til standardindstillingerne og \u00f8ger kun st\u00f8rrelsen for bestemte tekstblokke.<\/li>\n  <li><strong>Blokst\u00f8rrelse<\/strong>: For sm\u00e5 blokke forringer forholdet, for store \u00f8ger ventetiden. Jeg tester med repr\u00e6sentative payloads i stedet for at foretage en generel optimering.<\/li>\n  <li><strong>Flush-strategi<\/strong>: Aggressiv flushing reducerer bufferlatensen, men mindsker komprimeringen. For API\u2019er med serverstreaming v\u00e6lger jeg en tilbageholden flush-hyppighed.<\/li>\n<\/ul>\n\n<h2>Dynamisk indhold: Sweet Spot 4\u20136<\/h2>\n\n<p>N\u00e5r det g\u00e6lder HTML-, JSON- eller API-svar, komprimerer jeg dem i realtid og er meget opm\u00e6rksom p\u00e5 <strong>Svartid<\/strong>. Niveau 4\u20136 giver her som regel den bedste kombination af filst\u00f8rrelse, CPU-forbrug og latenstid. Det s\u00e6nker TTFB, holder belastningen inden for rimelige gr\u00e6nser og \u00f8ger reservekapaciteten ved spidsbelastninger. N\u00e5r jeg tester h\u00f8jere niveauer, ser jeg ofte stigende CPU-tider uden m\u00e6rkbar fordel p\u00e5 nettet. Hvis du vil dykke dybere ned i emnet, finder du mange praktiske detaljer om <a href=\"https:\/\/webhosting.de\/da\/komprimeringsniveau-cpu-belastning-gzip-brotli-optimering-datastrom\/\">CPU-belastning vs. niveau<\/a>, som netop illustrerer dette kompromis.<\/p>\n\n<p>Med <strong>Streaming<\/strong> (f.eks. SSE eller Chunked JSON) undg\u00e5r jeg til tider at bruge Brotli eller holder mig bevidst til lavere niveauer. Baggrund: Brotli udnytter konteksten over l\u00e6ngere afsnit; hyppig flushing \u00f8del\u00e6gger denne fordel og \u00f8ger CPU-belastningen. Jeg vurderer derfor for hver rute, om gennemstr\u00f8mning eller latenstid er vigtigst, og om mikrocacher kan h\u00e5ndtere svar med en sekunds forsinkelse.<\/p>\n\n<h2>Statiske ressourcer: Komprim\u00e9r p\u00e5 forh\u00e5nd<\/h2>\n\n<p>N\u00e5r det g\u00e6lder CSS, JavaScript og andre ressourcer, komprimerer jeg dem inden levering og accepterer st\u00f8rre <strong>beregningstid<\/strong> p\u00e5 build-serveren. Niveau 9\u201311 passer godt her, fordi omkostningerne kun opst\u00e5r \u00e9n gang, og hver ekstra besparelse t\u00e6ller p\u00e5 lang sigt. Det kan is\u00e6r betale sig ved mange tilbagevendende downloads og p\u00e5 langsomme forbindelser. Jeg gemmer de komprimerede artefakter ved siden af originalen og lader serveren levere det rigtige format afh\u00e6ngigt af klienten. Det er vigtigt at huske at afs\u00e6tte tilstr\u00e6kkelig CPU og RAM til buildet, s\u00e5 deploys k\u00f8rer problemfrit.<\/p>\n\n<p>I buildet fastl\u00e6gger jeg klare <strong>Udelukkelsesregler<\/strong> (f.eks. ingen .jpg\/.png\/.mp4\/.zip\/.woff2), versionsstyring og cache-busting via filnavne. P\u00e5 den m\u00e5de forbliver ETags konsistente, og jeg undg\u00e5r dobbeltkomprimering. Ved store pakker opdeler jeg filerne, hvis applikationen tillader det; mindre, tematisk sorterede filer kan bedre caches og drager uforholdsm\u00e6ssigt stor fordel af Brotli-ordforr\u00e5det.<\/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\/08\/brotliconference_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Brotli vs. Gzip i hverdagen<\/h2>\n\n<p>Tekstformater som HTML, CSS eller JS komprimeres som regel lidt mere med Brotli, mens Gzip ofte komprimerer hurtigere og mindre <strong>CPU<\/strong> kr\u00e6ves. Til live-komprimering p\u00e5 sider med h\u00f8j trafik har jeg derfor Gzip som reserve, hvis CPU-belastningen stiger. Til statiske ressourcer foretr\u00e6kker jeg Brotli, fordi den mindre overf\u00f8rselsst\u00f8rrelse g\u00f8r en forskel ved hver hentning. P\u00e5 \u00e6ldre systemer eller ved brug af proxyk\u00e6der forbliver jeg fleksibel og underst\u00f8tter begge formater. En god indf\u00f8ring i den direkte sammenligning findes i <a href=\"https:\/\/webhosting.de\/da\/brotli-vs-gzip-websteds-komprimering-lynhurtig-ydeevne\/\">Brotli vs. Gzip<\/a> med typiske styrker og svagheder.<\/p>\n\n<p>Det, der er vigtigt for mig, er <strong>Planl\u00e6gning af kapacitet<\/strong>: Hvis gennemstr\u00f8mningen (anmodninger pr. sekund) er m\u00e5leparameteren, vinder Gzip, n\u00e5r CPU-kapaciteten er begr\u00e6nset. Hvis b\u00e5ndbredde eller CDN-udg\u00e5ende trafik er dyr, tjener Brotli sig meget hurtigt ind p\u00e5 ressourcerne. Derfor kombinerer jeg de to: Brotli som standard for statiske ressourcer og Gzip som en fleksibel reserve i live-driften.<\/p>\n\n<h2>CPU-budget, latenstid og TTFB<\/h2>\n\n<p>Jeg definerer f\u00f8rst en klar <strong>CPU-budget<\/strong> pr. foresp\u00f8rgsel og tilpasser niveauet derefter. P\u00e5 den m\u00e5de undg\u00e5r jeg, at komprimering dominerer TTFB, eller at spidsbelastninger f\u00f8rer til fejl. Det er nyttigt at inddele efter anvendelsesform\u00e5l, hvor man bruger relative effekter i stedet for eksakte tal. Den f\u00f8lgende tabel viser, hvordan jeg sammenholder niveauer og scenarier. Den erstatter ikke en benchmark, men giver et p\u00e5lideligt udgangspunkt for test.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Brotli-niveau<\/th>\n      <th>CPU-\/tidsforbrug<\/th>\n      <th>St\u00f8rrelsesbesparelse<\/th>\n      <th>Velegnet til<\/th>\n      <th>Hint<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>1-3<\/td>\n      <td>lav<\/td>\n      <td>moderat<\/td>\n      <td>Live-komprimering med begr\u00e6nsede ressourcer<\/td>\n      <td><strong>Hurtig<\/strong>, men mindre besparelse<\/td>\n    <\/tr>\n    <tr>\n      <td>4-6<\/td>\n      <td>Medium<\/td>\n      <td>godt<\/td>\n      <td>Dynamiske HTML-\/API-svar<\/td>\n      <td>Ofte den <strong>Det s\u00f8de sted<\/strong> for TTFB<\/td>\n    <\/tr>\n    <tr>\n      <td>7\u20138<\/td>\n      <td>forh\u00f8jet<\/td>\n      <td>meget god<\/td>\n      <td>Blandede scenarier, dels live, dels forudindspillet<\/td>\n      <td>Kun hvis der er luft i <strong>CPU-budget<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>9-11<\/td>\n      <td>h\u00f8j<\/td>\n      <td>maksimalt<\/td>\n      <td>Forh\u00e5ndskomprimerede statiske ressourcer<\/td>\n      <td>Byggetiden stiger, overf\u00f8rslen falder<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Indholdsforhandling, Vary og cache-n\u00f8gler<\/h2>\n\n<p>For at sikre, at kunderne p\u00e5lideligt f\u00e5r den bedste l\u00f8sning, mener jeg, at <strong>Forhandling af indhold<\/strong> ren:<\/p>\n<ul>\n  <li><strong>Vary: Accept-kodning<\/strong> Det er absolut n\u00f8dvendigt, ellers leverer cacherne forkerte formater til de efterf\u00f8lgende klienter.<\/li>\n  <li>Gem den forkomprimerede .br-fil ved siden af originalfilen; serveren indstiller den korrekt <strong>Indholdskodning: br<\/strong> og den passende <strong>Indholdstype<\/strong>.<\/li>\n  <li>N\u00e5r det g\u00e6lder CDN'er, s\u00f8rger jeg for, at <strong>Cache-n\u00f8gler<\/strong> \u201eTag h\u00f8jde for \u201cAccept-Encoding\u00ab og cache Brotli og Gzip hver for sig.<\/li>\n  <li>Hvad ang\u00e5r ETag\/Last-Modified, holder jeg fast i min fremgangsm\u00e5de: Komprimerede og ukomprimerede filer f\u00e5r hver deres egne validatorer for at undg\u00e5 uoverensstemmelser.<\/li>\n<\/ul>\n<p>Jeg tester desuden, hvordan proxyservere og \u00e6ldre HTTP\/1.1-klienter reagerer. Hvis der er usikkerhed, prioriterer jeg stabilitet og lader Gzip v\u00e6re aktiveret eller leverer indholdet ukomprimeret.<\/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\/08\/brotli-compression-balance-4523.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Caching, ordb\u00f8ger og forkomprimering<\/h2>\n\n<p>Jeg aflaster serveren ved at <strong>Caching<\/strong> af komprimerede svar, hvor indholdet tillader det. Ved tilbagevendende m\u00f8nstre i teksten er det v\u00e6rd at se p\u00e5 ordb\u00f8ger, som \u00f8ger effektiviteten og reducerer tiden pr. foresp\u00f8rgsel. N\u00e5r jeg bruger prekomprimering, s\u00f8rger jeg for rene cache-headere og filnavne med endelser som .br, s\u00e5 serveren kan levere indholdet uden omkodning. For dynamisk indhold unders\u00f8ger jeg edge-caches eller microcaches med l\u00f8betider p\u00e5 f\u00e5 sekunder, hvilket aflaster hot paths betydeligt. P\u00e5 den m\u00e5de holder jeg CPU-forbruget forudsigeligt og sikrer ensartede svartider.<\/p>\n\n<p><strong>Ordb\u00f8ger<\/strong> Jeg bruger det m\u00e5lrettet, n\u00e5r mange svar indeholder lignende tokens (f.eks. navneomr\u00e5der, JSON-n\u00f8gler). Jeg holder ordb\u00f8gerne sm\u00e5 og versionerer dem, s\u00e5 jeg kan udskifte dem uden nedetid. For dynamiske API'er er fortjenesten mindre, men det betaler sig, hvis trafikken er homogen.<\/p>\n\n<h2>Konfiguration: Nginx, Apache, CDN<\/h2>\n\n<p>Jeg aktiverer Brotli m\u00e5lrettet pr. <strong>MIME-type<\/strong> og blokerer bin\u00e6re formater, som sj\u00e6ldent giver nogen fordel. I Nginx indstiller jeg via \u00bbmap\u00ab forskellige niveauer afh\u00e6ngigt af filst\u00f8rrelse og sti for at sk\u00e5ne \u00bbhot routes\u00ab. I Apache h\u00e5ndterer jeg det p\u00e5 samme m\u00e5de ved hj\u00e6lp af filterk\u00e6der og klare undtagelser. Ved CDN'er bruger jeg prekomprimering og Vary-headere, s\u00e5 klienter p\u00e5lideligt modtager det rigtige format. Vejledningen til giver et solidt udgangspunkt for ops\u00e6tninger <a href=\"https:\/\/webhosting.de\/da\/http-komprimering-konfiguration-ydeevneforbedring-optimeret\/\">HTTP-komprimering<\/a> med praktisk anvendelige muligheder.<\/p>\n\n<p>Derudover definerer jeg en <strong>Minimumst\u00f8rrelse<\/strong> (min_length), hvorfra komprimeringen tr\u00e6der i kraft, og s\u00f8rg for, at reverse-proxyer ikke komprimerer igen. Dobbeltkodning genkender jeg straks p\u00e5 fejlbeh\u00e6ftede Content-Length-headere eller klientfejl. For <strong>Delvist indhold (intervalforesp\u00f8rgsler)<\/strong> Jeg har originalfilerne klar; komprimerede versioner er her kun egnet i begr\u00e6nset omfang og kan forvirre cacherne.<\/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\/08\/tech_office_brotli_1537.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Overv\u00e5gning og benchmark-tests<\/h2>\n\n<p>Jeg m\u00e5ler hver \u00e6ndring i <strong>Niveauer<\/strong> med kontrollerede benchmarks og produktionsmetrikker. TTFB, gennemstr\u00f8mning, CPU-belastning pr. worker og fejlprocent under belastning er vigtige. For dynamiske ruter tester jeg p95\/p99-v\u00e6rdier, da ekstreme v\u00e6rdier pr\u00e6ger brugeroplevelsen. Jeg sammenligner desuden trafikmix og assetst\u00f8rrelser f\u00f8r og efter omstillingen for at identificere bivirkninger. F\u00f8rst n\u00e5r v\u00e6rdierne forbliver stabile over flere dage, erkl\u00e6rer jeg profilen for den nye baseline.<\/p>\n\n<p>Min <strong>Testdisciplin<\/strong> i kortform:<\/p>\n<ul>\n  <li>Brug repr\u00e6sentative payloads (lille\/mellem\/stor) og \u00e6gte headere.<\/li>\n  <li>Udf\u00f8r opvarmning, og k\u00f8r derefter m\u00e5levinduet med en stabil belastning.<\/li>\n  <li>Overv\u00e5g konkurrerende systemfaktorer (GC, I\/O, TLS-offload) hver for sig.<\/li>\n  <li>Sammenlign altid \u201elige mod lige\u201c: identiske seeds, identiske datas\u00e6t.<\/li>\n<\/ul>\n\n<h2>Sikkerhed og gr\u00e6nsetilf\u00e6lde<\/h2>\n\n<p>Komprimering kan fremme sidekanaler, hvis hemmelige tokens ender i reflekterede svar. Jeg <strong>Deaktiver komprimering<\/strong> p\u00e5 f\u00f8lsomme slutpunkter (login-forl\u00f8b, CSRF-tokens i HTML) eller adskil disse i egne ruter. Hvor det ikke kan undg\u00e5s, reducerer jeg konteksten (f.eks. ved hj\u00e6lp af mere neutrale skabeloner) for at minimere dataafh\u00e6ngige forskelle i l\u00e6ngden.<\/p>\n\n<p>Yderligere udfordringer fra praksis:<\/p>\n<ul>\n  <li><strong>Beskadigede genstande<\/strong> p\u00e5 grund af mislykkede builds: Kontroller checksummerne f\u00f8r implementering, og s\u00f8rg for, at filtyperne (.br) og MIME-typerne er korrekte.<\/li>\n  <li><strong>Uforenelige proxyservere<\/strong>: Aktiver fallback til Gzip ved uforklarlige 206\/Content-Encoding-fejl.<\/li>\n  <li><strong>Timeouts<\/strong> ved h\u00f8je niveauer: S\u00e6nk niveauet eller \u00f8g antallet af arbejdere\/CPU-kvoter.<\/li>\n  <li><strong>Manglende Vary-headere<\/strong>: F\u00f8rer til \u201eforkerte\u201c svar i CDN-cachen, hvilket viser sig som visningsfejl i visse browsere.<\/li>\n<\/ul>\n\n<h2>Prioriteter efter projektfase<\/h2>\n\n<p>I de tidlige faser holder jeg niveauet lavt til middel, s\u00e5 <strong>Iteration<\/strong> og s\u00f8rger for, at implementeringerne forbliver hurtige. S\u00e5 snart trafikken stiger, optimerer jeg de statiske ressourcer mere aggressivt og sikrer dynamiske svar ved at finde det optimale punkt. N\u00e5r der er risiko for spidsbelastninger, foretr\u00e6kker jeg at skalere worker- og cache-kapaciteter frem for at h\u00e6ve niveauet uden omtanke. Ved internationale m\u00e5lgrupper investerer jeg i prekomprimering og edge-caching, fordi hver millisekund p\u00e5 nettet t\u00e6ller. P\u00e5 den m\u00e5de forbliver platformen p\u00e5lidelig uden at spilde ressourcer.<\/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\/08\/BrotliKompression0034.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>WordPress og hosting i praksis<\/h2>\n\n<p>I WordPress-Stacks konfigurerer jeg Brotli p\u00e5 serversiden, ikke via <strong>Plugin<\/strong> i PHP-stien for at undg\u00e5 CPU-overhead. Jeg lader build-pipelines komprimere ressourcerne p\u00e5 forh\u00e5nd og kombinerer det med cache-invalidering efter deploy. Objektcache og sidecache reducerer desuden den dynamiske komprimering. Som sikkerhedsnet holder jeg Gzip aktivt, s\u00e5 selv eksotiske klienter f\u00e5r rene svar. Hvis du planl\u00e6gger at komme i gang, kan du f\u00f8lge denne praktiske vejledning og gradvist bev\u00e6ge dig op til h\u00f8jere niveauer, s\u00e5 snart telemetrien tillader det.<\/p>\n\n<p>N\u00e5r det g\u00e6lder multisite-ops\u00e6tninger og headless-temaer, mener jeg, at <strong>pro\u2011Route<\/strong> Der findes forskellige profiler: API-ruter med niveau 4\u20135, HTML-renderingsstier med 5\u20136 og statiske bundter, der udelukkende caches p\u00e5 forh\u00e5nd med 10\u201311. Det er vigtigt, at jeg knytter cache-n\u00f8gler og rydningslogik korrekt til de nye artefaktnavne, s\u00e5 der ikke forbliver for\u00e6ldede .br-filer i oml\u00f8b.<\/p>\n\n<h2>Fejlfinding og typiske faldgruber<\/h2>\n\n<p>Hvis noget hakker, g\u00e5r jeg systematisk til v\u00e6rks:<\/p>\n<ul>\n  <li><strong>Dobbelt kompression<\/strong>: Kontroller, om upstream (app-serveren) allerede komprimerer, og om edge-serveren koder det igen. L\u00f8sning: Lad kun \u00e9t sted st\u00e5 for det.<\/li>\n  <li><strong>Forkert Content-Length<\/strong>: Ved \u00bbTransfer-Encoding: chunked\u00ab m\u00e5 der ikke angives en fast l\u00e6ngde; ellers afbryder browseren.<\/li>\n  <li><strong>Manglende originaler<\/strong>: For Range-anmodninger, Alt-klienter og fejlfinding skal der absolut v\u00e6re ukomprimerede filer til r\u00e5dighed.<\/li>\n  <li><strong>For aggressivt niveau<\/strong>: Symptomerne er stigende p99-TTFB, sporadiske 5xx-fejl og CPU-m\u00e6tning. L\u00f8sning: S\u00e6nk niveauet eller \u00f8g caching.<\/li>\n  <li><strong>\u00c6ndring af aktivsammens\u00e6tningen<\/strong>: Efter opdateringer af framework \u00e6ndrer tokenhyppighederne sig \u2013 ratioen kan pludselig blive d\u00e5rligere. Udf\u00f8r en ny benchmarking og tilpas ordb\u00f8gerne.<\/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\/08\/brotli-kompression-cpu-4982.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Kort opsummeret<\/h2>\n\n<p>Jeg v\u00e6lger bevidst sv\u00e6rhedsgraden og knytter den til sv\u00e6re <strong>Metrikker<\/strong>. Til dynamisk indhold indstiller jeg som regel niveau 4\u20136, fordi TTFB er afg\u00f8rende, og CPU-spidsbelastninger bliver dyre. Statiske ressourcer indstiller jeg p\u00e5 forh\u00e5nd til niveau 9\u201311, da hver ekstra procentpoint i besparelse her giver en mangedoblet effekt. Brotli leverer ofte de bedste st\u00f8rrelser, mens Gzip scorer p\u00e5 hastighed og fungerer som fallback. Det afg\u00f8rende er stadig ens egen telemetri: Den, der m\u00e5ler og itererer, finder hurtigt den rigtige profil til trafik, hardware og brugeroplevelse.<\/p>","protected":false},"excerpt":{"rendered":"<p>F\u00e5 det bedste ud af Brotli-komprimering: S\u00e5dan finder du balancen mellem ydeevne, filst\u00f8rrelse og CPU-forbrug for hjemmesider og servere.<\/p>","protected":false},"author":1,"featured_media":20731,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-20738","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":"118","_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":"Brotli Compression","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":"20731","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/20738","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=20738"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/20738\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/20731"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=20738"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=20738"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=20738"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}