Gzip
Gzip ist ein langjährig etabliertes Komprimierungs-Verfahren, das Web-Inhalte beim Versand vom Server zum Browser auf einen Bruchteil ihrer Originalgröße reduziert – für Text-Inhalte üblicherweise auf etwa ein Viertel bis ein Drittel.
Gzip ist die Basis-Komprimierung im Web und seit Jahrzehnten universell unterstützt. Heute wird es in modernen Konfigurationen zunehmend von Brotli ergänzt; für ältere Browser-Konfigurationen und als Fallback bleibt es weiterhin relevant.
In einfachen Worten
Gzip funktioniert wie ein ZIP-Archiv für die Übertragungs-Strecke: HTML, CSS und JavaScript werden vom Server vor dem Versand verkleinert und im Browser unsichtbar wieder entpackt. Das Verfahren ist seit über zwei Jahrzehnten Standard und wird von praktisch jedem Server und jedem Browser unterstützt. In modernen Konfigurationen wird Gzip zunehmend von Brotli ergänzt, das Text-Inhalte stärker komprimiert. Gzip bleibt aber als Fallback für ältere Client-Konfigurationen relevant und ist überall dort die erste Wahl, wo Brotli noch nicht verfügbar ist. Für bereits komprimierte Formate (Bilder, Videos, PDF-Dateien) bringt Gzip keinen zusätzlichen Nutzen, weil diese in sich komprimiert sind.
Wozu brauche ich das?
Gzip-Aktivierung ist Pflicht-Konfiguration für jede produktive Website. Ohne Komprimierung werden Text-Inhalte in voller Größe übertragen – das verschwendet Bandbreite, verlängert Ladezeiten und belastet die mobilen Daten-Volumen der Besucher unnötig. Die Aktivierung ist mit überschaubarem Aufwand verbunden und ohne Zusatzkosten verfügbar. In der Praxis ist eine Website ohne aktivierte Komprimierung heute ein klares Konfigurations-Defizit.
Beispiel aus der Praxis
Eine Beispiel-Rechnung verdeutlicht die Größenordnung: Eine HTML-Seite mit rund 95 KB Originalgröße wird mit aktivierter Gzip-Komprimierung auf etwa 22 KB ausgeliefert – eine Reduktion im Bereich von rund drei Vierteln ist für Text-Inhalte üblich. Bei hohen Seitenaufruf-Zahlen pro Monat summiert sich der Spar-Effekt auf mehrere Gigabyte Traffic, ohne dass eine Zeile Anwendungs-Code geändert wird. Auf einer durchschnittlichen mobilen Verbindung verkürzt sich die initiale Ladezeit und damit der Largest Contentful Paint messbar – genug, dass Besucher den Unterschied als spürbar schneller wahrnehmen.
Wirtschaftlicher Nutzen
Die Aktivierung erfordert eine einmalige Server-Konfiguration mit überschaubarem Aufwand und ist ohne Zusatzkosten verfügbar. Der Nutzen wirkt dauerhaft: geringere Hosting-Bandbreite, kürzere Ladezeiten und eine bessere Bewertung in den Core Web Vitals. Gegenüber Brotli liegt Gzip bei Text-Inhalten in der Komprimierungs-Wirkung leicht zurück; wer die Wahl hat, aktiviert beide Verfahren parallel (Brotli bevorzugt, Gzip als Fallback). Eine produktive Website ohne aktivierte Komprimierung verschenkt einen der einfachsten Performance-Hebel überhaupt.
Typische Fehler
- Gzip nur für HTML aktiviert, während CSS und JavaScript unkomprimiert bleiben – ein erheblicher Teil des Hebels wird verschenkt.
- Bereits komprimierte Dateien (JPEG, MP4, ZIP-Archive) erneut durch Gzip geschickt – kostet Server-Ressourcen, ohne nennenswerten Spar-Effekt.
- Komprimierungs-Stufe auf das Maximum gesetzt – die CPU-Last steigt deutlich, der zusätzliche Spar-Effekt bleibt marginal.
- Hinter einem Vermittlungsserver aktiviert, der die Inhalte davor wieder entpackt – die Komprimierung wird auf der letzten Strecke wirkungslos.
- Nach der Aktivierung nicht überprüft, ob die Auslieferung tatsächlich komprimiert läuft – die Konfiguration sieht aktiv aus, wirkt aber nicht.
Worauf achten?
- Mindestens für HTML, CSS, JavaScript, SVG und JSON aktivieren – das sind die mit dem größten Spar-Effekt.
- Komprimierungs-Stufe in einem moderaten Bereich (etwa fünf bis sechs) wählen – die Balance aus CPU-Last und Spar-Effekt liegt dort am günstigsten.
- Binär-Formate (Bilder, Videos, PDF-Dateien, Archive) explizit vom Komprimierungs-Vorgang ausnehmen – sie sind bereits komprimiert.
- Mit einem geeigneten Werkzeug oder einer manuellen Anfrage prüfen, ob die Auslieferung den erwarteten Content-Encoding-Header zurückgibt.
- Wo möglich, parallel Brotli aktivieren – moderne Browser bevorzugen Brotli automatisch und greifen nur als Fallback auf Gzip zurück.
Häufig gestellte Fragen
Was macht Gzip eigentlich?
Gzip komprimiert Text-Inhalte (HTML, CSS, JavaScript, JSON, SVG) vor dem Versand vom Server zum Browser. Der Browser entpackt die Daten unsichtbar wieder. Das Verfahren reduziert das übertragene Volumen und verkürzt damit Ladezeiten.
Brauche ich Gzip noch, wenn ich Brotli einsetze?
Ja – als Fallback. Brotli wird von modernen Browsern bevorzugt, ist aber nicht in jeder Client-Konfiguration verfügbar. Eine saubere Server-Konfiguration liefert Brotli an Browser aus, die es unterstützen, und Gzip an den Rest.
Welche Komprimierungs-Stufe ist optimal?
In der Regel eine moderate Stufe im Bereich von fünf bis sechs. Höhere Stufen erhöhen die CPU-Last des Servers spürbar, ohne dass der zusätzliche Spar-Effekt das in der Praxis rechtfertigt – besonders bei dynamisch zur Laufzeit komprimierten Inhalten.
Warum sollten Bilder nicht durch Gzip geschickt werden?
Bilder im JPEG-, PNG- oder AVIF-Format sind bereits in sich komprimiert. Eine zusätzliche Gzip-Bearbeitung kostet Server-Ressourcen, ohne nennenswert Volumen einzusparen. Sinnvoll ist Gzip ausschließlich für Text-basierte Formate.
Wie prüfe ich, ob meine Website komprimiert ausgeliefert wird?
Über die Browser-Entwickler-Werkzeuge im Reiter „Netzwerk": Dort lässt sich pro Datei der Antwort-Header Content-Encoding einsehen. Alternativ über eine manuelle Anfrage mit explizitem Accept-Encoding-Header oder über ein Werkzeug für die Performance-Bewertung.