Brotli er en komprimeringsalgoritme til overførsel af tekstbaserede filer over HTTP. Den bruges typisk til HTML, CSS, JavaScript, SVG, JSON og XML. Når browseren understøtter Brotli, sender den br i HTTP-headeren Accept-Encoding, og serveren eller CDN’et kan svare med samme komprimering i Content-Encoding.
Brotli ændrer ikke filens indhold eller funktion. Browseren dekomprimerer blot svaret, før den parser HTML, CSS eller JavaScript. Sammenlignet med Gzip giver Brotli ofte mindre overførte filer, især for CSS og JavaScript. Det kan gøre en forskel på mobilnet, hvor hver ekstra byte og rundtur har større betydning.
Hvorfor det betyder noget for hastighed
Komprimering reducerer tiden, der bruges på at overføre render-kritiske filer. Et mindre HTML-dokument kan nå browseren hurtigere; mindre CSS og JavaScript kan starte tidligere i critical rendering path. Det kan forbedre First Contentful Paint og bidrage indirekte til LCP.
Det er dog ikke en erstatning for at reducere mængden af kode. En stor JavaScript-bundle kan blive mindre med Brotli, men browseren skal stadig parse og køre den. Kombinér derfor komprimering med minification, fjernelse af ubrugt CSS og JavaScript samt fornuftig indlæsningsrækkefølge.
Hvornår Brotli ikke hjælper
Allerede komprimerede formater som WebP, AVIF, JPEG, PNG, MP4 og PDF bliver som regel ikke mindre på en meningsfuld måde. At bruge CPU på at forsøge yderligere komprimering er typisk spild. Billeder skal i stedet leveres i korrekt format og dimension, og et LCP-billede skal prioriteres separat.
Brotli kan også have en komprimeringsomkostning på serveren. På dynamiske, ikke-cachede svar bør hostingplatformen vælge en fornuftig indstilling. For statiske eller cachede assets produceres den komprimerede variant ofte én gang og leveres derefter hurtigt fra cache eller CDN.
WordPress-vinklen
På en WordPress-side aktiveres Brotli normalt i webserveren, på hostingen eller hos CDN’et — eksempelvis Cloudflare — ikke i WordPress-kernen. Et cache-plugin kan gøre HTML cachebar og minimere CSS/JavaScript, men det er serverlaget, der skal sende den korrekte HTTP-header. Det er vigtigt, at cachen varierer korrekt efter Accept-Encoding, så en Brotli-variant ikke sendes til en klient, der kun accepterer Gzip.
- Aktivér Brotli i CDN- eller hostingkontrolpanelet, hvis det er tilgængeligt.
- Behold Gzip som fallback, hvor infrastrukturen håndterer det automatisk.
- Kontrollér at HTML, CSS og JavaScript faktisk svarer med
Content-Encoding: br. - Undgå “dobbeltkomprimering” af filer, som allerede er komprimerede.
Sådan kontrollerer du opsætningen
Åbn DevTools Network, vælg et HTML-, CSS- eller JavaScript-svar, og se under Response Headers efter content-encoding: br. Du kan også sammenligne “transferred” med den ukomprimerede ressource-størrelse. Test med cache ryddet, fordi et lokalt cached svar ikke viser den aktuelle levering.
Hvis Brotli mangler, skal du undersøge CDN, reverse proxy og webserverkonfiguration — ikke blot WordPress’ pluginindstillinger. Mål derefter den samlede effekt sammen med filstørrelser og render-kritiske ressourcer. Brotli er en god standard i leveringslaget, men den største performancegevinst kommer stadig af at sende færre og vigtigere filer.