Accept-Encoding im HTTP verständlich erklärt: Komprimierung

Der HTTP-Header Accept-Encoding ist ein Request-Header (Anfrage-Header), den der Webbrowser an den Server sendet. Er dient der Inhaltsaushandlung (Content Negotiation) für die Datenkomprimierung. Der Browser teilt dem Server mit, welche Komprimierungsalgorithmen (wie Brotli oder Gzip) er entschlüsseln kann. Der Server komprimiert den Antworttext daraufhin im unterstützten Format, was die übertragene Dateigrösse massiv reduziert und die Ladezeit der Website optimiert.

Die Komprimierung ist eine der wirkungsvollsten Performance-Massnahmen überhaupt und zahlt direkt auf die Core Web Vitals ein. Sie arbeitet eng mit dem Content-Type (welche Ressourcen komprimiert werden) und dem Caching über Cache-Control zusammen – erst das Zusammenspiel dieser Header liefert minimale Ladezeiten.

Der Ablauf der Komprimierungs-Aushandlung

Die Übermittlung komprimierter Daten erfolgt in einem einfachen zweiseitigen Handshake:

1. Die Anfrage (Client-Request): Der Webbrowser ruft eine Seite auf und sendet im Header mit, welche Algorithmen er beherrscht: Accept-Encoding: gzip, deflate, br (br steht hierbei für den modernen Algorithmus Brotli).
2. Die Verarbeitung (Server-Response): Der Server liest die Liste. Er wählt den besten verfügbaren Algorithmus (bevorzugt Brotli) und komprimiert den HTML-Code vor dem Absenden.
3. Die Antwort (Server-Response): Der Server sendet die komprimierten Daten zurück und teilt dem Browser über den Antwort-Header Content-Encoding mit, wie die Daten entpackt werden müssen: Content-Encoding: br Der Browser entpackt die Datei im RAM und rendert sie.

---

Die wichtigsten Komprimierungsmethoden im Vergleich

1. Gzip (GNU zip)

Gzip ist der dienstälteste und am weitesten verbreitete Komprimierungsstandard im Web. Er basiert auf dem DEFLATE-Algorithmus. Gzip ist extrem schnell bei der Komprimierung und Dekomprimierung und wird von 100 % aller modernen Browser unterstützt.

2. Brotli (br)

Brotli wurde 2015 von Google vorgestellt und ist der moderne Standard für performante Websites.

• Der Vorteil: Brotli nutzt ein integriertes statisches Wörterbuch mit häufigen HTML-, CSS- und JS-Textbausteinen. Dadurch erzielt es bei gleichem Rechenaufwand eine um 15 % bis 30 % höhere Komprimierungsrate als Gzip.
• Der Nutzen: Kleinere Dateien bedeuten weniger Datenübertragung über das Mobilfunknetz, was das Ladezeit-Scoring (PageSpeed / Core Web Vitals) stark verbessert.

3. Deflate & Identity

• deflate: Ein älterer Standard, der heute kaum noch aktiv genutzt wird.
• identity: Signalisiert, dass die Daten unkomprimiert (im Klartext) übertragen werden sollen.

Die Algorithmen im direkten Vergleich

Algorithmus	Kennung (Content-Encoding)	Kompressionsrate	Browser-Support	Einsatzempfehlung
Brotli	br	Sehr hoch	Alle modernen Browser	Bevorzugt für Text-Assets
Gzip	gzip	Hoch	100 %	Universelles Fallback
Deflate	deflate	Mittel	Hoch	Nicht empfohlen (Altlast)
Identity	identity	Keine	100 %	Bilder/Videos, bereits komprimiert

Welche Dateitypen komprimiert werden sollten

Dateityp	Komprimieren?	Begründung
HTML, CSS, JS	Ja	Hohe Ersparnis bei Klartext
JSON, XML, SVG	Ja	Textbasiert, stark komprimierbar
JPEG, PNG, WebP	Nein	Bereits entropiekodiert
MP4, WOFF2	Nein	Eigene Kompression integriert

---

Caching-Probleme vermeiden mit Vary

Nutzen Unternehmen ein Content Delivery Network (CDN) oder Proxy-Caches, müssen Webserver den Header Vary: Accept-Encoding mitsenden.

• Ohne diesen Header könnte ein CDN die komprimierte Brotli-Version einer CSS-Datei im globalen Cache speichern und an alle nachfolgenden Besucher ausliefern.
• Ruft ein Besucher mit einem sehr alten Browser (ohne Brotli-Support) die Seite auf, erhält er die komprimierten Brotli-Bytes und sieht nur unlesbaren Zeichensalat.
• Der Vary-Header zwingt das CDN, separate Cache-Versionen für gzip, br und unkomprimierte Anfragen zu verwalten.

---

Praxisbeispiel: komprimierte Antwort auf der Leitung

Eine typische, korrekt komprimierte Server-Antwort für eine CSS-Datei sieht so aus – entscheidend sind Content-Encoding und Vary:

HTTP/1.1 200 OK
Content-Type: text/css; charset=utf-8
Content-Encoding: br
Vary: Accept-Encoding
Cache-Control: public, max-age=31536000, immutable

Der Effekt ist erheblich: Eine 120 KB grosse CSS-Datei schrumpft mit Gzip auf etwa 25 KB und mit Brotli auf rund 20 KB – eine Reduktion um über 80 Prozent, die sich unmittelbar in einem schnelleren LCP niederschlägt.

[!TIP] Die Aktivierung von Brotli-Komprimierung auf Serverebene ist eine der einfachsten und effektivsten Massnahmen zur Optimierung der Core Web Vitals. Prüfen Sie, ob Ihre Website Brotli oder Gzip korrekt ausliefert, mit dem HTTP Header Check auf balou.tools.