Brotli

Kort fortalt: Brotli (br) er en komprimeringsmetode til tekstbaserede filer. Det gør HTML, CSS og JavaScript mindre, så de kan downloades hurtigere.

Hvad handler det om?

Serveren komprimerer tekst-baserede filer før de sendes til browseren.

Browseren sender typisk en Accept-Encoding header (fx br, gzip, deflate). Hvis serveren/CDN’et understøtter Brotli og vælger at bruge det, får du ofte mindre payload end gzip.

Hvilken indflydelse har Brotli?

Brotli kan påvirke:

• download tid for HTML/CSS/JS (mindre data)
• oplevelse på mobil (mindre dataforbrug)
• stabilitet (hurtigere levering af kritiske filer)

Det påvirker typisk ikke CPU på klienten mærkbart i negativ retning i moderne browsere, men komprimering på serveren kan have en cost hvis du komprimerer “on the fly” uden caching.

Hvornår blev Brotli udbredt?

Brotli blev populært i takt med:

• browser-support for br
• CDNs der kan komprimere effektivt ved edge
• flere og større JS/CSS bundles på moderne sites

I dag er Brotli en standard anbefaling for tekstbaserede assets.

Typiske forbedringer

• Sørg for at br er aktiveret for HTML/CSS/JS/JSON
• Kombinér med caching (cache-control) og CDN hvor muligt

Brotli vs gzip (hvornår hvad?)

• Brotli giver ofte bedre kompression (mindre filer) på tekst
• gzip er stadig udbredt og fungerer fint som fallback

Det bedste setup er typisk:

• br for moderne browsere
• gzip som fallback

Konkrete anbefalinger (praktisk)

1) Aktivér Brotli på CDN hvis muligt

Edge-komprimering er ofte det nemmeste og mest effektive, fordi:

• CPU-arbejdet sker på CDN’et
• du får komprimering tæt på brugeren

2) Komprimér kun tekstbaserede filer

Brotli er relevant for:

• HTML
• CSS
• JS
• JSON
• SVG

Det giver sjældent mening for:

• allerede komprimerede billeder (AVIF/WebP/JPEG/PNG)
• video

3) Sørg for caching af komprimerede varianter

Hvis serveren komprimerer dynamisk, kan det være dyrt. Ideelt:

• komprimer ved build eller cache lagrede varianter
• brug CDN caching hvor muligt

Sådan tester du om Brotli er aktivt

I DevTools Network:

• klik på en request til HTML/CSS/JS
• kig efter content-encoding: br

Du kan også sammenligne “transferred size” med og uden Brotli.

Typiske faldgruber

• du tror Brotli er aktivt, men content-encoding er stadig gzip
• du komprimerer billeder (giver ingen mening)
• du har store, ikke-minificerede bundles (komprimering hjælper, men minificering er stadig vigtigt)

Brotli og forholdet til TTFB, FCP og LCP

Brotli reducerer primært overført datamængde. Det betyder:

• hurtigere levering af HTML/CSS/JS
• mindre pres på netværk, især mobil
• potentielt bedre FCP/LCP når kritiske filer ankommer hurtigere

Hvis TTFB er høj pga. backend, løser Brotli ikke årsagen, men kan stadig forbedre overførsel efter første byte.

Hvornår gevinsten er størst

Størst effekt ses ofte når:

• CSS/JS er relativt tunge
• mange brugere har mobilnetværk
• siden har flere tekstbaserede responses (HTML/JSON)

Mindre effekt ses når:

• filer allerede er små
• flaskehalsen primært er CPU/JavaScript execution

Driftsperspektiv: stabilt setup over tid

For at undgå regressions bør du have:

• ens komprimeringspolitik på tværs af miljøer
• monitorering af response headers
• jævnlige stikprøver efter deploy

Det sikrer at content-encoding: br ikke “forsvinder” efter ændringer i server/CDN.

Konkrete anbefalinger til produktion

1. Aktivér Brotli for teksttyper i CDN/server.
2. Hold gzip som fallback.
3. Kombinér med minificering og caching.
4. Verificér headers på repræsentative sider.

Denne kombination giver normalt bedre og mere stabil performance end at fokusere på enkeltstående tweaks.

Almindelige misforståelser

• “Brotli gør alt hurtigt”
  Nej, det hjælper mest på transferstørrelse, ikke på tung frontend-logik.

• “Vi har CDN, så vi er dækket”
  Kun hvis komprimering faktisk er aktiv og korrekt konfigureret.

• “Komprimering erstatter minificering”
  Nej, de supplerer hinanden.

Udvidet tjekliste

• content-encoding: br ses på HTML/CSS/JS i produktion
• gzip fallback fungerer
• Minificering og cache headers er på plads
• Målinger før/efter viser lavere transfer size
• Ingen komprimering af allerede komprimerede medietyper