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 grosse HTML-Datei kann auf 15-20 KB komprimiert werden. Der Browser dekomprimiert sie sofort, und der Besucher bemerkt nichts ausser 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, enthaelt er einen Accept-Encoding-Header, der dem Server mitteilt, welche Komprimierungsalgorithmen er unterstuetzt:

Accept-Encoding: gzip, deflate, br

Dieser Header sagt, dass der Browser Gzip, Deflate und Brotli (abgekuerzt als br) verarbeiten kann. Der Server waehlt den besten Algorithmus, den er unterstuetzt, komprimiert den Response-Body und fuegt 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 unterstuetzt (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 fuer verschiedene Dateitypen waehlen oder sogar unkomprimierten Inhalt fuer Dateien liefern, die nicht von Komprimierung profitieren.

Gzip: Der etablierte Standard

Gzip ist seit den spaeten 1990er Jahren das Arbeitspferd der Web-Komprimierung. Es basiert auf dem DEFLATE-Algorithmus (eine Kombination aus LZ77 und Huffman-Kodierung) und wird von buchstaeblich jedem heute genutzten Browser und Webserver unterstuetzt. 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 standardmaessig 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 grosse CSS-Datei wird zu etwa 15-30 KB.

Die Hauptvorteile von Gzip sind seine Universalitaet (es funktioniert ueberall), 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 veroeffentlicht. Es wurde speziell fuer 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 Woerterbuch haeufiger Zeichenketten in Web-Inhalten (HTML-Tags, CSS-Eigenschaften, JavaScript-Schluesselwoerter usw.).

Brotli verwendet ebenfalls konfigurierbare Komprimierungsstufen von 0 bis 11. Auf vergleichbaren Qualitaetsstufen erzeugt Brotli kleineren Output als Gzip, aber auf den hoechsten Stufen (10-11) ist es deutlich langsamer beim Komprimieren. Das macht hochstufige Brotli-Komprimierung ideal fuer statische Assets, die einmal vorkomprimiert und vielfach ausgeliefert werden, aber weniger geeignet fuer dynamische Inhalte, die bei jeder Anfrage komprimiert werden muessen.

Eine wichtige Einschraenkung: Brotli funktioniert nur ueber HTTPS. Browser akzeptieren keine Brotli-komprimierten Antworten ueber 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 fuer 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 laedt, bedeutet dieser Unterschied etwa 15-30 KB weniger uebertragene Daten pro Seitenaufruf.
• Komprimierungsgeschwindigkeit: Gzip auf Stufe 6 ist schneller als Brotli auf einer aequivalenten Qualitaetsstufe. Fuer 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 geschwindigkeitsmaessig 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-Unterstuetzung: alle modernen Browser unterstuetzen sowohl Gzip als auch Brotli. Der Internet Explorer (inzwischen eingestellt) unterstuetzte kein Brotli, aber Edge, Chrome, Firefox und Safari alle schon. Die globale Browser-Unterstuetzung fuer Brotli liegt ueber 96%.
• Server-Unterstuetzung: Apache unterstuetzt Brotli durch mod_brotli (verfuegbar seit Apache 2.4.26). Nginx unterstuetzt es durch das ngx_brotli-Modul (ein Drittanbieter-Modul, das separat kompiliert werden muss). LiteSpeed hat eingebaute Brotli-Unterstuetzung. Die meisten Managed-Hosting-Anbieter und CDNs unterstuetzen beide.
• HTTPS-Anforderung: Brotli erfordert HTTPS. Gzip funktioniert sowohl ueber HTTP als auch HTTPS.

In der Praxis sind viele Server so konfiguriert, dass sie Brotli bevorzugen, wenn der Browser es unterstuetzt, und andernfalls auf Gzip zurueckfallen. Das gibt dir die beste Komprimierung fuer moderne Browser bei gleichzeitiger Kompatibilitaet mit aelteren Clients.

Wie man Komprimierung in Apache aktiviert

Fuer Apache aktivierst du Gzip-Komprimierung ueber mod_deflate (verwirrend benannt, aber es verwendet Gzip, nicht rohes Deflate). Fuege Folgendes in deine .htaccess-Datei ein:

  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

Fuer Brotli auf Apache brauchst du mod_brotli:

  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

Wie man Komprimierung in Nginx aktiviert

Fuer 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;

Fuer 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 (ueblich bei Shared Hosting), koennen mehrere WordPress-Caching-Plugins die Komprimierung fuer dich uebernehmen:

• 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: enthaelt eine Gzip-Komprimierungsoption, die gecachte Seiten komprimiert.
• Autoptimize: obwohl primaer ein CSS/JS-Optimierungs-Plugin, kann es auch komprimierte Versionen der generierten Dateien ausliefern.

Bedenke, dass es ueberfluessig 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 koennen).

Welche Dateitypen am meisten von Komprimierung profitieren

Komprimierung funktioniert am besten bei textbasierten, repetitiven Inhalten. Hier eine Aufschluesselung 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 Schluesselwoerter, 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 zusaetzliche serverseitige Komprimierung minimalen Nutzen bietet. WOFF-Fonts enthalten leichtere Komprimierung und koennen 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 Dateigroesse sogar leicht erhoehen.
• Video-Dateien (MP4, WebM): bereits mit hocheffizienten Codecs komprimiert. Serverseitige Komprimierung fuegt 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. Zusaetzliche Komprimierung bietet vernachlaessigbare Einsparungen.

Bereits komprimierte Dateien zu komprimieren verschwendet Server-CPU bei jeder Anfrage und kann sogar zu leicht groesserem Output fuehren. Die meisten Webserver-Konfigurationen und WordPress-Caching-Plugins beschraenken die Komprimierung korrekt auf textbasierte MIME-Typen, aber es lohnt sich, dein Setup zu ueberpruefen, um sicherzustellen, dass Binaerdateien ausgeschlossen sind.

Was InspectWP prueft

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 Ueberblick erhaeltst, ob dein Server korrekt konfiguriert ist, um Uebertragungsgroessen zu reduzieren.