Accept Encoding Header
Was ist der Accept Encoding Header?
Der Accept Encoding Header ist ein HTTP-Anfrage-Header, mit dem ein Browser oder anderer Client dem Webserver mitteilt, welche Komprimierungsverfahren er verarbeiten kann. Der Server kann daraufhin beispielsweise gzip oder Brotli auswählen, die Antwort komprimieren und das verwendete Verfahren im Content-Encoding-Header angeben.
Der Accept Encoding Header gehört zur Kommunikation zwischen Client und Webserver. Er ermöglicht die Übertragung komprimierter HTML-, CSS-, JavaScript- oder Textdateien und kann dadurch die zu übertragende Datenmenge deutlich reduzieren. Im HTTP-Protokoll lautet die standardisierte Schreibweise des Feldnamens Accept-Encoding.
So funktioniert die Inhaltskomprimierung
Bei einem Seitenaufruf sendet der Browser eine HTTP-Anfrage an den Webserver. Das Feld Accept-Encoding enthält eine Liste der Komprimierungsverfahren, die der Browser unterstützt. Eine typische Anfrage kann beispielsweise Accept-Encoding: gzip, deflate, br enthalten.
Der Server prüft diese Liste und wählt ein unterstütztes Verfahren aus. Komprimiert er die Antwort mit gzip, enthält die HTTP-Antwort den Header Content-Encoding: gzip. Der Browser erkennt dadurch, dass er die übertragenen Daten vor der Darstellung entpacken muss.
Accept-Encoding: gzip, br senden. Liefert der Server anschließend Content-Encoding: br, wurde die Antwort mit Brotli komprimiert. Fehlt der Content-Encoding-Header, wurde die Ressource in der Regel unkomprimiert übertragen.Verfügbare Encoding-Verfahren
Die im Anfrage-Header genannten Werte werden als Content Codings bezeichnet. Welche Variante der Server tatsächlich verwendet, hängt von der Serverkonfiguration, dem Dateityp, dem Browser und gegebenenfalls einem vorgeschalteten Content Delivery Network ab.
| Wert | Bedeutung | Typischer Einsatz |
|---|---|---|
gzip | Weit verbreitetes Komprimierungsverfahren | HTML, CSS, JavaScript, JSON und XML |
br | Brotli-Komprimierung mit häufig hoher Kompressionsrate | Moderne Websites über HTTPS |
deflate | Älteres Verfahren auf Basis des Deflate-Algorithmus | Kompatibilität mit älteren Systemen |
zstd | Zstandard mit schneller Komprimierung und Dekomprimierung | Unterstützte moderne Browser- und Serverumgebungen |
identity | Übertragung ohne Komprimierung | Fallback oder ausdrücklich unkomprimierte Antworten |
* | Platzhalter für beliebige weitere Verfahren | Allgemeine Akzeptanz nicht einzeln genannter Codings |
Prioritäten mit q-Werten
Ein Client kann die bevorzugte Reihenfolge über sogenannte Qualitätswerte festlegen. Bei Accept-Encoding: br;q=1.0, gzip;q=0.8, *;q=0.1 wird Brotli bevorzugt, gzip bleibt eine mögliche Alternative und andere Verfahren erhalten eine niedrigere Priorität. Der Wert q=0 erklärt ein Verfahren ausdrücklich für nicht akzeptabel.
Unterschied zu Content-Encoding
Der Unterschied zwischen Accept-Encoding und Content-Encoding liegt in Richtung und Funktion. Accept-Encoding wird mit der Anfrage gesendet und beschreibt die Fähigkeiten des Clients. Content-Encoding steht in der Serverantwort und nennt die tatsächlich auf die Antwort angewandte Komprimierung.
Die beiden Header müssen zueinander passen. Sendet ein Server eine Brotli-komprimierte Antwort, obwohl der Client Brotli nicht unterstützt, kann der Browser den Inhalt möglicherweise nicht korrekt verarbeiten. Nennt der Server dagegen kein Content-Encoding, darf die Antwort nicht ohne entsprechende Kennzeichnung komprimiert sein.
Abgrenzung zu Transfer-Encoding
Content-Encoding verändert die Darstellung einer Ressource für die Übertragung, ohne ihren eigentlichen Medientyp zu ändern. Transfer-Encoding beschreibt dagegen, wie eine HTTP-Nachricht zwischen einzelnen Kommunikationspartnern übertragen wird. Ein bekanntes Beispiel aus HTTP/1.1 ist chunked, bei dem die Nachricht in mehreren Abschnitten übertragen wird.
Nutzen für Ladezeit und SEO
Komprimierte Textressourcen benötigen weniger Übertragungsvolumen. Das verkürzt vor allem bei langsamen Mobilfunkverbindungen die Downloadphase und kann das Rendering einer Seite beschleunigen. Bereits komprimierte Formate wie JPEG, WebP, AVIF, MP4 oder ZIP profitieren gewöhnlich kaum von einer zusätzlichen HTTP-Komprimierung.
Der Header ist kein direkter Ranking-Faktor. Seine korrekte Nutzung unterstützt jedoch die technische Qualität einer Website, weil kleinere HTML-, CSS- und JavaScript-Dateien schneller übertragen werden können. Das kann Kennzahlen wie den Largest Contentful Paint beeinflussen, sofern die komprimierten Ressourcen für die Darstellung des größten sichtbaren Elements benötigt werden.
Eine technische Prüfung sollte den Header deshalb zusammen mit Caching, Serverantwortzeit, Dateigröße und den Core Web Vitals bewerten. Ein Ladezeiten-Check mit PageSpeed-Analyse zeigt, ob fehlende Textkomprimierung oder andere technische Engpässe vorliegen. Eine umfassendere Bewertung erfolgt im Rahmen eines technischen SEO-Audits.
Prüfe die Ladezeit und technische Auslieferung deiner Website direkt:
Header richtig konfigurieren
Die Komprimierung wird üblicherweise auf dem Webserver, im Hosting-System oder über ein Content Delivery Network aktiviert. Apache nutzt dafür häufig Module wie mod_deflate oder mod_brotli. Bei Nginx stehen entsprechende gzip- und Brotli-Einstellungen zur Verfügung. Auch viele verwaltete Hosting-Plattformen übernehmen die Aushandlung automatisch.
Der Antwort-Header Vary: Accept-Encoding informiert zwischengeschaltete Caches darüber, dass unterschiedliche Versionen einer Ressource existieren können. Ein Cache darf dadurch beispielsweise eine gzip-komprimierte Variante von einer Brotli- oder unkomprimierten Variante unterscheiden.
Vary: Accept-Encoding korrekt verarbeitet wird und ob bereits komprimierte Dateien nicht erneut komprimiert werden.Typische Fehler bei der Prüfung
Ein häufiger Fehler besteht darin, ausschließlich die Größe einer lokalen Datei mit der übertragenen Größe im Browser zu vergleichen. Für die technische Bewertung zählt die tatsächlich über das Netzwerk übertragene Datenmenge. Browser-Entwicklertools zeigen deshalb häufig sowohl die übertragene als auch die entpackte Ressourcengröße an.
Auch eine fehlende gzip-Antwort ist nicht automatisch ein Fehler. Wenn der Server stattdessen Brotli oder Zstandard verwendet, findet bereits eine Komprimierung statt. Maßgeblich sind der Content-Encoding-Header, die übertragene Dateigröße und die Unterstützung durch den anfragenden Client.
Bei einer technischen Onpage-Optimierung sollte die Komprimierung gemeinsam mit Caching, Bildformaten, JavaScript-Ausführung und Serverleistung betrachtet werden. Einzelne Header-Werte liefern nur einen Ausschnitt der tatsächlichen Ladezeit.
Häufige Fragen zur HTTP-Komprimierung
Wie kann ich den Accept-Encoding-Header sehen?
Öffne die Entwicklertools deines Browsers, rufe den Bereich Netzwerk auf und lade die Seite neu. In den Anfrage-Headern der ausgewählten Ressource findest du das Feld Accept-Encoding. Der Content-Encoding-Header steht dagegen in den Antwort-Headern.
Welches Komprimierungsverfahren sollte ein Server verwenden?
Der Server sollte ein Verfahren auswählen, das der Client unterstützt und das zur technischen Umgebung passt. Brotli und Zstandard können bei unterstützten Clients effizient sein, während gzip eine weit verbreitete Kompatibilitätsoption bleibt.
Kann der Accept-Encoding-Header fehlen?
Ja, ein Client kann eine Anfrage ohne diesen Header senden. Der Server muss dann davon ausgehen, dass keine ausdrücklich genannten Komprimierungsverfahren vereinbart wurden, und kann den Inhalt unkomprimiert ausliefern.
Sollte man Bilder mit gzip komprimieren?
Bereits komprimierte Bildformate wie JPEG, WebP und AVIF werden durch gzip meistens kaum kleiner. Die zusätzliche Verarbeitung kann daher mehr Rechenaufwand verursachen, ohne die übertragene Datenmenge nennenswert zu reduzieren.
Warum steht im Header br?
Der Wert br bezeichnet Brotli. Nennt ein Client br im Anfrage-Header, kann er Brotli-komprimierte Antworten verarbeiten. Verwendet der Server das Verfahren, bestätigt er dies mit Content-Encoding: br.
Beeinflusst HTTP-Komprimierung die Core Web Vitals?
HTTP-Komprimierung kann die Ladezeit textbasierter Ressourcen verkürzen und dadurch einzelne Core Web Vitals indirekt verbessern. Die tatsächliche Wirkung hängt von Dateigröße, Verbindung, Serverleistung, Caching und dem Aufbau der Seite ab.
Wenn du Header, Ladezeiten und weitere technische SEO-Signale im Zusammenhang prüfen lassen möchtest, bietet ein Potenzialcheck eine fachliche Einordnung deiner Domain.
Sie haben noch Fragen?
