HTTP-Kompression nach Dateityp: Was zu messen ist

HTTP-Kompression verkleinert den Antwortinhalt für die Übertragung. Ob gzip, Brotli oder zstd lohnt, hängt vom konkreten Inhalt, der Kompressionsstufe und den Kosten der Verarbeitung ab. Eine Dateiendung allein liefert keine zuverlässige Entscheidung.

Text zuerst prüfen, bereits komprimierte Formate getrennt betrachten

HTML, CSS, JavaScript, JSON, XML und SVG sind häufig gute Kandidaten. Wiederkehrende Zeichenfolgen und andere statistische Muster ermöglichen kürzere Darstellungen. Minifizierung entfernt etwa Leerraum oder verkürzt Namen; wiederholte Schlüsselwörter und Strukturen bleiben trotzdem erhalten. Auch minifiziertes JavaScript kann deshalb deutlich schrumpfen. JSON besteht ebenfalls nicht zwangsläufig aus einmaligen Werten.

JPEG, PNG, WebP und AVIF verwenden bereits Kompression. WOFF2 verarbeitet Schriftdaten mit speziellen Transformationen und Brotli. Eine zusätzliche HTTP-Kodierung bringt bei solchen Dateien oft wenig, kann aber je nach Datei noch Bytes sparen oder zusätzliche Bytes verursachen. Eine unverändert ausgelieferte Datei belegt nur die Serverentscheidung, nicht das Ergebnis eines tatsächlich durchgeführten zweiten Kompressionsversuchs.

SVG ist XML-Text und gehört trotz Bildfunktion zu den Textkandidaten. ICO ist dagegen ein Container: Möglich sind unter anderem Bitmapdaten und bereits komprimierte PNG-Bilder. Deshalb ist weder „jedes ICO ist unkomprimiert“ noch „jedes Bild ist schon optimal komprimiert“ richtig.

Keine allgemeine Grenze bei hundert Byte

Auch kleine Antworten können schrumpfen. Ein lokaler Test vom 25. Oktober 2026 verwendet exakt 80 ASCII-Zeichen a. gzip mit Stufe 6 erzeugt 24 Byte, Brotli mit Stufe 5 erzeugt 10 Byte und zstd mit Stufe 3 erzeugt 21 Byte. Die drei Eingabezeichen abc wachsen dagegen auf 23, 7 und 16 Byte. Alle sechs Ergebnisse wurden wieder dekodiert und bytegenau mit der Eingabe verglichen.

Das sind künstliche Beispiele für Inhaltsabhängigkeit, keine Messung von Webseiten oder Ladezeiten. Formatversionen und Einstellungen können Ergebnisse ändern. Eine Mindestgröße in der Serverkonfiguration ist eine betriebliche Abwägung, keine mathematische Grenze für Komprimierbarkeit.

Auch der Format-Overhead unterscheidet sich: gzip enthält eine Prüfsumme, der normale Brotli-Datenstrom keine, bei zstd ist eine Inhaltsprüfsumme optional. Eine einheitliche Erklärung mit „Kopf und Prüfsumme bei jedem Format“ wäre deshalb falsch.

Ein aussagekräftiger Vergleich braucht denselben Inhalt

1. Für jede Variante dieselbe endgültige Ressourcen-URL, dieselben relevanten Anfragebedingungen und denselben Messzeitraum verwenden. Dynamische Inhalte können sich schon zwischen zwei Abrufen ändern.
2. HTTP-Status, endgültigen Inhaltstyp und tatsächliches Content-Encoding prüfen. Ein Angebot von br erzwingt keine Brotli-Antwort; eine Sperrseite kann sogar mit Status 200 erscheinen.
3. Antworten vollständig dekodieren und den Inhalt bytegenau oder mit einem geeigneten Hash vergleichen. Unterschiedliche oder abgeschnittene Inhalte aus dem Größenvergleich ausschließen.
4. Für gleiche Inhalte kodierte Antwortbytes durch unkodierte Inhaltsbytes teilen. Beispiel: 20 KiB aus 100 KiB ergeben 20 Prozent Restgröße beziehungsweise 80 Prozent Ersparnis.
5. Mehrere Durchläufe und getrennte Zeitmessungen verwenden, wenn Aussagen über Geschwindigkeit oder CPU-Kosten erforderlich sind. Vorab komprimierte statische Dateien und dynamische Kompression haben unterschiedliche Kosten.

size_download von curl erfasst heruntergeladene Nutzdatenbytes, keine vollständige Netzwerkrechnung einschließlich HTTP-Headern, TLS und Paketaufwand. Bei --compressed kann die gespeicherte Datei bereits dekodiert sein; deren Dateigröße ist dann eine andere Messgröße. Die lokale curl-Version muss die angebotene Kodierung unterstützen.

Cache-Varianten und Validatoren prüfen

Wenn die Repräsentation anhand von Accept-Encoding gewählt wird, beschreibt Vary: Accept-Encoding diese Auswahl für Caches. Die Prüfung muss die relevanten kodierten und unkodierten Antworten umfassen. Ein fehlender Header kann bei wiederverwendbaren Antworten zur falschen Variantenwahl beitragen; eine kaputte Seite ist dadurch allein noch nicht nachgewiesen. Speicherregeln und weitere Cache-Konfiguration zählen ebenfalls.

Ein ETag ist eine Versionsmarkierung in der Serverantwort. Verschiedene kodierte Bytefolgen benötigen unterschiedliche starke ETags. Ein gemeinsamer schwacher Validator mit W/ kann inhaltlich gleichwertige Varianten, etwa eine komprimierte und eine unkomprimierte Fassung derselben Seite, kennzeichnen, ersetzt aber keine Prüfung der Inhalte oder der Einsatzbedingungen. Unterschiedliche ETag-Werte allein beweisen noch keine korrekte Implementierung.

Was der Kompressionsprüfer tatsächlich zeigt

Der Kompressions-Aushandlungsprüfer ruft eine Ressource nacheinander mit identity, gzip, br, zstd und einer festen Kombination ab. Die als Browser bezeichnete Variante ist ein curl-Abruf mit gzip, deflate, br, zstd, keine echte Browsermessung und kein universeller Browserheader.

Der aktuelle Prüfer meldet unterschiedliche dekodierte Inhalte, berechnet Größenquoten aber trotzdem weiter. Das Dekodierlimit liegt bei 3 MiB. Solche Abweichungen, abgeschnittene Antworten und Fehlerseiten machen den Vergleich unbrauchbar. Außerdem prüft die Vary-Auswertung nur eine kodierte Variante; die Typklassifikation untersucht keine Dateiinhalte. Das Werkzeug liefert daher Hinweise, keine vollständige Abnahme der Serverkonfiguration.