GZIP-Komprimierung

Die Gzip-Komprimierung ist ein verlustfreies Verfahren, das die Größe von Dateien reduziert, bevor ein Webserver sie an den Browser überträgt. Sie basiert auf dem DEFLATE-Algorithmus, der zwei Techniken kombiniert: LZ77 erkennt wiederkehrende Zeichenketten und ersetzt sie durch Referenzen, die Huffman-Codierung weist häufigen Zeichen kürzere Bitfolgen zu. Der Server kennzeichnet die komprimierte Antwort mit dem Header Content-Encoding gzip, der Browser entpackt sie automatisch. So werden weniger Daten übertragen und die Seite lädt schneller.

Bei textbasierten Dateien wie HTML, CSS, JavaScript, JSON, XML und SVG sind typischerweise 60 bis 80 Prozent Ersparnis realistisch, weil diese Formate viele Wiederholungen enthalten. Der genaue Wert hängt vom Inhalt ab. Bereits komprimierte Formate wie Bilder, Videos oder WOFF2-Fonts lassen sich dagegen kaum weiter verkleinern.

Komprimiert werden sollten textbasierte Dateien mit wiederkehrenden Mustern: HTML, CSS, JavaScript, JSON, XML und SVG. Nicht komprimiert werden sollten bereits komprimierte Formate wie JPEG, PNG, WebP, MP4, MP3 und ZIP sowie moderne Webfonts im WOFF2-Format, die intern schon mit Brotli komprimiert sind. Diese noch einmal zu komprimieren bringt keinen Nutzen und kostet nur zusätzliche Rechenzeit.

Die Komprimierung wird serverseitig aktiviert. Beim Webserver Nginx genügt die Direktive gzip on mit einer Liste der zu komprimierenden Dateitypen, beim Apache-Server übernimmt das Modul mod_deflate diese Aufgabe. Statische Dateien lassen sich auch vorab komprimieren. Wer keinen Serverzugriff hat, nutzt Hosting-Einstellungen oder ein Performance-Plugin, das die Komprimierung mit wenigen Klicks aktiviert. Wichtig ist, die Komprimierung nur an einer Stelle zu aktivieren, nicht gleichzeitig auf Server, Plugin und CDN.

Öffnen Sie die Entwicklertools des Browsers mit F12, wechseln Sie zum Netzwerk-Tab und laden Sie die Seite neu. Klicken Sie eine Datei an und suchen Sie im Antwort-Header nach Content-Encoding. Steht dort gzip, br oder zstd, ist die Komprimierung aktiv. Zusätzlich sollte die übertragene Größe deutlich kleiner sein als die entpackte Größe. Alternativ lässt sich der Header über Online-Tools oder mit dem Kommandozeilen-Werkzeug curl prüfen.

Beide sind HTTP-Header, mit denen Browser und Server das Komprimierungsverfahren aushandeln. Im Accept-Encoding-Header teilt der Browser mit, welche Verfahren er unterstützt, etwa gzip, br und zstd. Der Server wählt daraus eines aus und nennt es im Content-Encoding-Header der Antwort. So bekommt jeder Browser eine Variante, die er entpacken kann; ältere Clients erhalten zur Not eine unkomprimierte Fassung.

Beide sind Komprimierungsverfahren für das Web. Brotli wurde 2015 von Google eingeführt und ist seit 2016 in allen großen Browsern verfügbar. Es komprimiert Text spürbar stärker als Gzip, besonders HTML, CSS und JavaScript, benötigt bei hohen Stufen aber mehr Rechenzeit und wird nur über HTTPS angeboten. Gzip ist dafür universell unterstützt, schnell und einfach. In der Praxis nutzt man Brotli bevorzugt für statische Textinhalte und Gzip als Fallback für Clients ohne Brotli-Unterstützung.

Zstandard, kurz zstd, ist ein verlustfreies Komprimierungsverfahren von Meta. Im Web wird es seit Chrome 123 im März 2024 als Content-Encoding zstd unterstützt, mittlerweile auch von Firefox und neueren Safari-Versionen, und nur über HTTPS. Es zeichnet sich durch sehr schnelles Entpacken bei einer Kompressionsrate nahe an Brotli aus. Wo zstd nicht unterstützt wird, fällt der Server automatisch auf Brotli oder Gzip zurück.

Am besten beide. Moderne Webserver und CDNs bieten Gzip, Brotli und teils zstd gleichzeitig an und liefern jedem Browser über die Header-Aushandlung automatisch die passende Variante. Für statische Textinhalte über HTTPS ist Brotli wegen der stärkeren Kompression heute oft die bevorzugte Wahl, während Gzip als universeller Fallback für ältere oder eingeschränkte Clients dient. Sie müssen sich also nicht für ein einziges Verfahren entscheiden.

Indirekt ja. Komprimierung verringert die übertragene Datenmenge, wodurch Seiten schneller laden, was sich positiv auf den Largest Contentful Paint und die mobile Ladezeit auswirkt. Die Ladegeschwindigkeit ist seit dem Speed Update 2018 und dem Page Experience Update 2021 ein bestätigtes, aber gegenüber dem Inhalt nachrangiges Rankingsignal. Komprimierung allein verbessert kein Ranking, ist aber ein sinnvoller Baustein einer guten technischen Performance.

Ja. Wenn mehrere Ebenen gleichzeitig komprimieren, etwa Server, ein Plugin und das CDN, verschwendet das Rechenzeit und kann in seltenen Fällen zu fehlerhaften oder paradoxerweise langsameren Antworten führen. Aktivieren Sie die Komprimierung deshalb nur an einer Stelle, idealerweise auf Server- oder CDN-Ebene, und stellen Sie sicher, dass nicht zusätzlich ein Plugin dieselbe Aufgabe übernimmt.

Komprimierung wirkt vor allem auf die übertragene Datenmenge und damit indirekt auf den Largest Contentful Paint, weil Inhalte schneller geladen werden. Die Core Web Vitals umfassen heute den Largest Contentful Paint, den Interaction to Next Paint, der im März 2024 den First Input Delay abgelöst hat, sowie den Cumulative Layout Shift. Auf INP und CLS hat Komprimierung kaum direkten Einfluss; sie verbessert primär die Ladezeit-Komponente.