Was ist Gzip- und Brotli-Komprimierung?

Gzip und Brotli sind Komprimierungsalgorithmen, die dein Webserver verwendet, um Dateien zu verkleinern, bevor er sie an den Browser des Besuchers sendet. Die Idee ist einfach: Textbasierte Dateien wie HTML, CSS und JavaScript enthalten viele wiederkehrende Muster, und Komprimierungsalgorithmen sind sehr gut darin, diese Redundanz zu finden und zu eliminieren. Eine 100 KB große HTML-Datei kann auf 15–20 KB komprimiert werden. Der Browser dekomprimiert sie sofort, und der Besucher bemerkt nichts außer einem schnelleren Seitenaufbau.

Wenn du schon einmal einen Ordner auf deinem Computer gezippt hast, verstehst du bereits das Grundkonzept. Web-Komprimierung funktioniert genauso, nur automatisch und transparent. Der Server komprimiert die Antwort, der Browser dekomprimiert sie, und weder der Entwickler noch der Besucher muss etwas Besonderes tun (vorausgesetzt, der Server ist korrekt konfiguriert).

Wie Web-Komprimierung auf Protokollebene funktioniert

Jedes Mal, wenn ein Browser eine HTTP-Anfrage sendet, enthält er einen Accept-Encoding-Header, der dem Server mitteilt, welche Komprimierungsalgorithmen er unterstützt:

Accept-Encoding: gzip, deflate, br

Dieser Header sagt, dass der Browser Gzip, Deflate und Brotli (abgekürzt als br) verarbeiten kann. Der Server wählt den besten Algorithmus, den er unterstützt, komprimiert den Response-Body und fügt einen Content-Encoding-Header hinzu, um dem Browser mitzuteilen, welcher Algorithmus verwendet wurde:

Content-Encoding: gzip

oder:

Content-Encoding: br

Der Browser liest diesen Header, wendet den entsprechenden Dekomprimierungsalgorithmus an und rendert den Inhalt. Wenn der Server keine Komprimierung unterstützt (oder sie nicht konfiguriert ist), sendet er die Antwort unkomprimiert, und kein Content-Encoding-Header ist vorhanden.

Diese Aushandlung geschieht bei jeder einzelnen Anfrage. Der Server kann verschiedene Komprimierungsmethoden für verschiedene Dateitypen wählen oder sogar unkomprimierten Inhalt für Dateien liefern, die nicht von Komprimierung profitieren.

Gzip: Der etablierte Standard

Gzip ist seit den späten 1990er Jahren das Arbeitspferd der Web-Komprimierung. Es basiert auf dem DEFLATE-Algorithmus (eine Kombination aus LZ77 und Huffman-Kodierung) und wird von buchstäblich jedem heute genutzten Browser und Webserver unterstützt. Wenn Leute von „Komprimierung aktivieren" auf einem Webserver sprechen, meinen sie normalerweise Gzip.

Gzip arbeitet mit konfigurierbaren Komprimierungsstufen, typischerweise von 1 (schnellste, geringste Komprimierung) bis 9 (langsamste, beste Komprimierung). Die meisten Webserver verwenden standardmäßig Stufe 6, was eine gute Balance zwischen Komprimierungsrate und CPU-Auslastung bietet. Auf Stufe 6 erreicht Gzip typischerweise 70–85 % Komprimierung bei textbasierten Dateien. Das bedeutet, eine 100 KB große CSS-Datei wird zu etwa 15–30 KB.

Die Hauptvorteile von Gzip sind seine Universalität (es funktioniert überall), seine Geschwindigkeit auf moderaten Komprimierungsstufen und die Jahrzehnte an Optimierung, die in seine Implementierungen geflossen sind. Der Hauptnachteil ist, dass es nicht ganz so gut komprimiert wie Brotli, besonders bei kleineren Dateien.

Brotli: Die moderne Alternative

Brotli wurde von Google entwickelt und 2016 als RFC 7932 veröffentlicht. Es wurde speziell für Web-Inhalte entworfen und erreicht 15–25 % bessere Komprimierungsraten als Gzip bei typischen Web-Assets. Brotli erreicht dies durch einen ausgefeilteren Komprimierungsalgorithmus und ein eingebautes Wörterbuch häufiger Zeichenketten in Web-Inhalten (HTML-Tags, CSS-Eigenschaften, JavaScript-Schlüsselwörter usw.).

Brotli verwendet ebenfalls konfigurierbare Komprimierungsstufen von 0 bis 11. Auf vergleichbaren Qualitätsstufen erzeugt Brotli kleineren Output als Gzip, aber auf den höchsten Stufen (10–11) ist es deutlich langsamer beim Komprimieren. Das macht hochstufige Brotli-Komprimierung ideal für statische Assets, die einmal vorkomprimiert und vielfach ausgeliefert werden, aber weniger geeignet für dynamische Inhalte, die bei jeder Anfrage komprimiert werden müssen.

Eine wichtige Einschränkung: Brotli funktioniert nur über HTTPS. Browser akzeptieren keine Brotli-komprimierten Antworten über einfache HTTP-Verbindungen. Da die meisten WordPress-Seiten ohnehin auf HTTPS sein sollten (und HTTP/2 es erfordert), ist das selten ein praktisches Problem.

Gzip vs. Brotli: Ein praktischer Vergleich

So vergleichen sich die beiden Algorithmen bei Metriken, die für WordPress-Betreiber relevant sind:

• Komprimierungsrate: Brotli erzeugt typischerweise Dateien, die 15–25 % kleiner sind als Gzip auf vergleichbaren Komprimierungsstufen. Bei einer WordPress-Seite, die 500 KB komprimierbare Assets lädt, bedeutet dieser Unterschied etwa 15–30 KB weniger übertragene Daten pro Seitenaufruf.
• Komprimierungsgeschwindigkeit: Gzip auf Stufe 6 ist schneller als Brotli auf einer äquivalenten Qualitätsstufe. Für dynamische Inhalte (PHP-generierte HTML-Seiten) ist Gzip oft die praktischere Wahl, weil die Komprimierung bei jeder Anfrage stattfindet. Brotli auf den Stufen 1–4 ist geschwindigkeitsmäßig mit Gzip vergleichbar und komprimiert trotzdem etwas besser.
• Dekomprimierungsgeschwindigkeit: Brotli dekomprimiert etwas schneller als Gzip, was bedeutet, dass der Browser den Inhalt marginal schneller verarbeiten kann. Der Unterschied ist klein, aber konsistent.
• Browser-Unterstützung: Alle modernen Browser unterstützen sowohl Gzip als auch Brotli. Der Internet Explorer (inzwischen eingestellt) unterstützte kein Brotli, aber Edge, Chrome, Firefox und Safari unterstützten es alle schon. Die globale Browser-Unterstützung für Brotli liegt über 96 %.
• Server-Unterstützung: Apache unterstützt Brotli durch mod_brotli (verfügbar seit Apache 2.4.26). Nginx unterstützt es durch das ngx_brotli-Modul (ein Drittanbieter-Modul, das separat kompiliert werden muss). LiteSpeed hat eingebaute Brotli-Unterstützung. Die meisten Managed-Hosting-Anbieter und CDNs unterstützen beide.
• HTTPS-Anforderung: Brotli erfordert HTTPS. Gzip funktioniert sowohl über HTTP als auch HTTPS.

In der Praxis sind viele Server so konfiguriert, dass sie Brotli bevorzugen, wenn der Browser es unterstützt, und andernfalls auf Gzip zurückfallen. Das gibt dir die beste Komprimierung für moderne Browser bei gleichzeitiger Kompatibilität mit älteren Clients.

Wie man Komprimierung in Apache aktiviert

Für Apache aktivierst du Gzip-Komprimierung über mod_deflate (verwirrend benannt, aber es verwendet Gzip, nicht rohes Deflate). Füge Folgendes in deine .htaccess-Datei ein:

<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html
  AddOutputFilterByType DEFLATE text/css
  AddOutputFilterByType DEFLATE text/javascript
  AddOutputFilterByType DEFLATE application/javascript
  AddOutputFilterByType DEFLATE application/json
  AddOutputFilterByType DEFLATE application/xml
  AddOutputFilterByType DEFLATE image/svg+xml
  AddOutputFilterByType DEFLATE application/font-woff2
</IfModule>

Für Brotli auf Apache brauchst du mod_brotli:

<IfModule mod_brotli.c>
  AddOutputFilterByType BROTLI_COMPRESS text/html
  AddOutputFilterByType BROTLI_COMPRESS text/css
  AddOutputFilterByType BROTLI_COMPRESS text/javascript
  AddOutputFilterByType BROTLI_COMPRESS application/javascript
  AddOutputFilterByType BROTLI_COMPRESS application/json
</IfModule>

Wie man Komprimierung in Nginx aktiviert

Für Nginx ist Gzip eingebaut und muss nur in der Konfiguration aktiviert werden:

gzip on;
gzip_vary on;
gzip_min_length 1024;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml image/svg+xml;

Für Brotli auf Nginx, nach Installation des ngx_brotli-Moduls:

brotli on;
brotli_comp_level 6;
brotli_types text/plain text/css application/json application/javascript text/xml application/xml image/svg+xml;

WordPress-Caching-Plugins und Komprimierung

Wenn du keinen Zugriff auf deine Serverkonfiguration hast (üblich bei Shared Hosting), können mehrere WordPress-Caching-Plugins die Komprimierung für dich übernehmen:

• WP Rocket: aktiviert Gzip-Komprimierung automatisch, indem es Regeln in deine .htaccess-Datei schreibt. Es erstellt auch vorkomprimierte statische HTML-Cache-Dateien.
• W3 Total Cache: bietet Gzip-Komprimierung als konfigurierbare Option in seinen Browser-Cache-Einstellungen. Es kann auch vorkomprimierte Dateien ausliefern.
• LiteSpeed Cache: wenn dein Host LiteSpeed Server betreibt, aktiviert dieses Plugin automatisch sowohl Gzip- als auch Brotli-Komprimierung.
• WP Super Cache: enthält eine Gzip-Komprimierungsoption, die gecachte Seiten komprimiert.
• Autoptimize: obwohl primär ein CSS/JS-Optimierungs-Plugin, kann es auch komprimierte Versionen der generierten Dateien ausliefern.

Bedenke, dass es überflüssig ist, Komprimierung durch ein Plugin zu aktivieren, wenn dein Server sie bereits auf Server-Ebene handhabt. Das kann manchmal Konflikte verursachen (doppelte Komprimierung, die Browser nicht dekomprimieren können).

Welche Dateitypen am meisten von Komprimierung profitieren

Komprimierung funktioniert am besten bei textbasierten, repetitiven Inhalten. Hier eine Aufschlüsselung nach Dateityp:

• HTML: komprimiert extrem gut (70–90 % Reduktion). WordPress-generierte HTML-Seiten sind voll von wiederkehrenden Tag-Strukturen, Klassennamen und Leerzeichen.
• CSS: komprimiert sehr gut (80–90 % Reduktion). Stylesheets enthalten viele wiederholte Eigenschaftsnamen und Selektoren.
• JavaScript: komprimiert sehr gut (70–85 % Reduktion). JS-Dateien haben wiederholte Schlüsselwörter, Funktionsnamen und strukturelle Muster.
• SVG: komprimiert extrem gut (80–95 % Reduktion). SVGs sind XML-basiert und hochgradig repetitiv.
• JSON: komprimiert sehr gut (75–90 % Reduktion). API-Antworten und Konfigurationsdaten profitieren erheblich.
• XML und RSS-Feeds: komprimieren sehr gut aufgrund ihrer repetitiven Tag-Struktur.
• Web-Fonts (WOFF/WOFF2): WOFF2-Fonts enthalten bereits intern Brotli-Komprimierung, sodass zusätzliche serverseitige Komprimierung minimalen Nutzen bietet. WOFF-Fonts enthalten leichtere Komprimierung und können leicht von Gzip profitieren.

Was NICHT komprimiert werden sollte

Nicht alle Dateitypen profitieren von Komprimierung, und einige sollten aktiv ausgeschlossen werden:

• JPEG-, PNG-, WebP-, AVIF-Bilder: diese Formate sind bereits komprimiert. Sie durch Gzip oder Brotli laufen zu lassen, verschwendet CPU-Zeit und kann die Dateigröße sogar leicht erhöhen.
• Video-Dateien (MP4, WebM): bereits mit hocheffizienten Codecs komprimiert. Serverseitige Komprimierung fügt Overhead ohne Nutzen hinzu.
• Audio-Dateien (MP3, AAC, OGG): wie bei Video, bereits komprimiert.
• ZIP, GZIP und andere Archive: per Definition bereits komprimiert.
• PDF-Dateien: die meisten PDFs verwenden interne Komprimierung. Zusätzliche Komprimierung bietet vernachlässigbare Einsparungen.

Bereits komprimierte Dateien zu komprimieren, verschwendet Server-CPU bei jeder Anfrage und kann sogar zu leicht größerem Output führen. Die meisten Webserver-Konfigurationen und WordPress-Caching-Plugins beschränken die Komprimierung korrekt auf textbasierte MIME-Typen, aber es lohnt sich, dein Setup zu überprüfen, um sicherzustellen, dass Binärdateien ausgeschlossen sind.

Was InspectWP prüft

InspectWP untersucht den Content-Encoding-Response-Header deiner WordPress-Seite, um festzustellen, ob Komprimierung aktiv ist. Es sucht spezifisch nach gzip, br (Brotli) oder deflate im Header-Wert. Wenn keine Komprimierung erkannt wird, markiert der Report dies als Performance-Problem mit der Empfehlung, entweder Gzip- oder Brotli-Komprimierung zu aktivieren. Die erkannte Komprimierungsmethode wird im Performance-Abschnitt des Reports angezeigt, sodass du einen klaren Überblick erhältst, ob dein Server korrekt konfiguriert ist, um Übertragungsgrößen zu reduzieren.