{"id":15679,"date":"2026-11-07T13:15:00","date_gmt":"2026-11-07T12:15:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=15679"},"modified":"2026-10-26T13:32:34","modified_gmt":"2026-10-26T12:32:34","slug":"http-kompression-nach-dateityp-was-zu-messen-ist","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/web-entwicklung\/tutorials-de-web-entwicklung\/http-kompression-nach-dateityp-was-zu-messen-ist\/","title":{"rendered":"HTTP-Kompression nach Dateityp: Was zu messen ist"},"content":{"rendered":"

HTTP-Kompression verkleinert den Antwortinhalt f\u00fcr die \u00dcbertragung. Ob gzip, Brotli oder zstd lohnt, h\u00e4ngt vom konkreten Inhalt, der Kompressionsstufe und den Kosten der Verarbeitung ab. Eine Dateiendung allein liefert keine zuverl\u00e4ssige Entscheidung.<\/p>\n

\"Textkandidaten,
Textkandidaten, Dateiaufbau und Bedingungen f\u00fcr g\u00fcltige Gr\u00f6\u00dfenvergleiche.<\/figcaption><\/figure>\n

Text zuerst pr\u00fcfen, bereits komprimierte Formate getrennt betrachten<\/h2>\n

HTML, CSS, JavaScript, JSON, XML und SVG sind h\u00e4ufig gute Kandidaten. Wiederkehrende Zeichenfolgen und andere statistische Muster erm\u00f6glichen k\u00fcrzere Darstellungen. Minifizierung entfernt etwa Leerraum oder verk\u00fcrzt Namen; wiederholte Schl\u00fcsselw\u00f6rter und Strukturen bleiben trotzdem erhalten. Auch minifiziertes JavaScript kann deshalb deutlich schrumpfen. JSON besteht ebenfalls nicht zwangsl\u00e4ufig aus einmaligen Werten.<\/p>\n

JPEG, PNG, WebP und AVIF verwenden bereits Kompression. WOFF2 verarbeitet Schriftdaten mit speziellen Transformationen und Brotli. Eine zus\u00e4tzliche HTTP-Kodierung bringt bei solchen Dateien oft wenig, kann aber je nach Datei noch Bytes sparen oder zus\u00e4tzliche Bytes verursachen. Eine unver\u00e4ndert ausgelieferte Datei belegt nur die Serverentscheidung, nicht das Ergebnis eines tats\u00e4chlich durchgef\u00fchrten zweiten Kompressionsversuchs.<\/p>\n

SVG ist XML-Text und geh\u00f6rt trotz Bildfunktion zu den Textkandidaten. ICO ist dagegen ein Container: M\u00f6glich sind unter anderem Bitmapdaten und bereits komprimierte PNG-Bilder. Deshalb ist weder \u201ejedes ICO ist unkomprimiert\u201c noch \u201ejedes Bild ist schon optimal komprimiert\u201c richtig.<\/p>\n

Keine allgemeine Grenze bei hundert Byte<\/h2>\n

Auch kleine Antworten k\u00f6nnen schrumpfen. Ein lokaler Test vom 25. Oktober 2026 verwendet exakt 80 ASCII-Zeichen a<\/code>. 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<\/code> wachsen dagegen auf 23, 7 und 16 Byte. Alle sechs Ergebnisse wurden wieder dekodiert und bytegenau mit der Eingabe verglichen.<\/p>\n

Das sind k\u00fcnstliche Beispiele f\u00fcr Inhaltsabh\u00e4ngigkeit, keine Messung von Webseiten oder Ladezeiten. Formatversionen und Einstellungen k\u00f6nnen Ergebnisse \u00e4ndern. Eine Mindestgr\u00f6\u00dfe in der Serverkonfiguration ist eine betriebliche Abw\u00e4gung, keine mathematische Grenze f\u00fcr Komprimierbarkeit.<\/p>\n

Auch der Format-Overhead unterscheidet sich: gzip enth\u00e4lt eine Pr\u00fcfsumme, der normale Brotli-Datenstrom keine, bei zstd ist eine Inhaltspr\u00fcfsumme optional. Eine einheitliche Erkl\u00e4rung mit \u201eKopf und Pr\u00fcfsumme bei jedem Format\u201c w\u00e4re deshalb falsch.<\/p>\n

Ein aussagekr\u00e4ftiger Vergleich braucht denselben Inhalt<\/h2>\n
    \n
  1. F\u00fcr jede Variante dieselbe endg\u00fcltige Ressourcen-URL, dieselben relevanten Anfragebedingungen und denselben Messzeitraum verwenden. Dynamische Inhalte k\u00f6nnen sich schon zwischen zwei Abrufen \u00e4ndern.<\/li>\n
  2. HTTP-Status, endg\u00fcltigen Inhaltstyp und tats\u00e4chliches Content-Encoding<\/code> pr\u00fcfen. Ein Angebot von br<\/code> erzwingt keine Brotli-Antwort; eine Sperrseite kann sogar mit Status 200 erscheinen.<\/li>\n
  3. Antworten vollst\u00e4ndig dekodieren und den Inhalt bytegenau oder mit einem geeigneten Hash vergleichen. Unterschiedliche oder abgeschnittene Inhalte aus dem Gr\u00f6\u00dfenvergleich ausschlie\u00dfen.<\/li>\n
  4. F\u00fcr gleiche Inhalte kodierte Antwortbytes durch unkodierte Inhaltsbytes teilen. Beispiel: 20 KiB aus 100 KiB ergeben 20 Prozent Restgr\u00f6\u00dfe beziehungsweise 80 Prozent Ersparnis.<\/li>\n
  5. Mehrere Durchl\u00e4ufe und getrennte Zeitmessungen verwenden, wenn Aussagen \u00fcber Geschwindigkeit oder CPU-Kosten erforderlich sind. Vorab komprimierte statische Dateien und dynamische Kompression haben unterschiedliche Kosten.<\/li>\n<\/ol>\n

    size_download<\/code> von curl erfasst heruntergeladene Nutzdatenbytes, keine vollst\u00e4ndige Netzwerkrechnung einschlie\u00dflich HTTP-Headern, TLS und Paketaufwand. Bei --compressed<\/code> kann die gespeicherte Datei bereits dekodiert sein; deren Dateigr\u00f6\u00dfe ist dann eine andere Messgr\u00f6\u00dfe. Die lokale curl-Version muss die angebotene Kodierung unterst\u00fctzen.<\/p>\n

    Cache-Varianten und Validatoren pr\u00fcfen<\/h2>\n

    Wenn die Repr\u00e4sentation anhand von Accept-Encoding<\/code> gew\u00e4hlt wird, beschreibt Vary: Accept-Encoding<\/code> diese Auswahl f\u00fcr Caches. Die Pr\u00fcfung 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\u00e4hlen ebenfalls.<\/p>\n

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

    Was der Kompressionspr\u00fcfer tats\u00e4chlich zeigt<\/h2>\n

    Der Kompressions-Aushandlungspr\u00fcfer<\/a> ruft eine Ressource nacheinander mit identity<\/code>, gzip<\/code>, br<\/code>, zstd<\/code> und einer festen Kombination ab. Die als Browser bezeichnete Variante ist ein curl-Abruf mit gzip, deflate, br, zstd<\/code>, keine echte Browsermessung und kein universeller Browserheader.<\/p>\n

    Der aktuelle Pr\u00fcfer meldet unterschiedliche dekodierte Inhalte, berechnet Gr\u00f6\u00dfenquoten aber trotzdem weiter. Das Dekodierlimit liegt bei 3 MiB. Solche Abweichungen, abgeschnittene Antworten und Fehlerseiten machen den Vergleich unbrauchbar. Au\u00dferdem pr\u00fcft die Vary-Auswertung nur eine kodierte Variante; die Typklassifikation untersucht keine Dateiinhalte. Das Werkzeug liefert daher Hinweise, keine vollst\u00e4ndige Abnahme der Serverkonfiguration.<\/p>\n

    \n

    Fragen und Antworten<\/h2>\n

    Ist Brotli immer kleiner als gzip?<\/h3>\n

    Nein. Inhalt, Implementierung, W\u00f6rterbuch und Kompressionsstufe beeinflussen das Ergebnis. Die kleinste Datei ist au\u00dferdem nicht automatisch die wirtschaftlichste Wahl f\u00fcr dynamische Antworten.<\/p>\n

    Welche Typen geh\u00f6ren in eine Kompressionsregel?<\/h3>\n

    Textformate sind ein sinnvoller Ausgangspunkt. Bereits komprimierte Formate und ICO ben\u00f6tigen eine gesonderte Betrachtung. Entscheidend sind vollst\u00e4ndige, inhaltlich gleiche Vergleichsantworten sowie die Anforderungen an Rechenzeit und Zwischenspeicherung.<\/p>\n

    Beweist eine kleinere Antwort eine schnellere Seite?<\/h3>\n

    Nein. Netzwerkbedingungen, Cachetreffer, Verbindungsaufbau, Serverarbeit und Browserausf\u00fchrung beeinflussen die Ladezeit. Eine Gr\u00f6\u00dfenmessung beantwortet zun\u00e4chst nur die Frage nach den gemessenen Antwortbytes.<\/p>\n<\/div>\n

    \n

    Quellen<\/h2>\n