Gzip oder Brotli? Warum Ihre Website ihre Seiten komprimieren muss

Eine unkomprimierte Seite kann 5-mal mehr wiegen als nötig. Test #01 prüft es sofort — und die Korrektur dauert weniger als 5 Minuten.

Eine typische WordPress-Seite erzeugt 50–200 KB HTML. Fügen Sie CSS, JavaScript und Webfonts hinzu — und Sie erreichen leicht 1 MB an textbasierten Ressourcen. Multipliziert mit jedem Besucher, jedem Seitenaufruf.

HTTP-Komprimierung löst dieses Problem: Der Server komprimiert die Antwort vor dem Senden, der Browser dekomprimiert sie beim Empfang. Die Übertragung schrumpft um 60–80 %. Der Besucher lädt weniger herunter, die Seite lädt schneller, und Google bemerkt es.

Das Überraschende? Etwa 15 % der WordPress-Websites haben die Komprimierung immer noch nicht aktiviert. Es ist keine komplexe Optimierung — es ist eine Servereinstellung. Und Test #01 von Orilyt erkennt es in unter 2 Sekunden.

Wie HTTP-Komprimierung funktioniert

Wenn Ihr Browser eine Anfrage sendet, enthält er einen Accept-Encoding-Header mit den unterstützten Komprimierungsformaten (typischerweise gzip und br für Brotli). Der Server wählt eines aus, komprimiert die Antwort und sendet sie mit einem Content-Encoding-Header zurück.

1. Gzip — der universelle Standard seit den 2000ern. Von allen Browsern und Servern unterstützt. Reduziert Text um 60–70 %. Schnelle Komprimierung und Dekomprimierung
2. Brotli (br) — von Google entwickelt, seit 2016 verfügbar. Komprimiert im Durchschnitt 15–25 % besser als Gzip. Von allen modernen Browsern unterstützt. Etwas langsamer beim Komprimieren, aber schneller beim Dekomprimieren
3. Keine Komprimierung — der Server sendet Rohtext. Der Browser empfängt 3- bis 5-mal mehr Daten als nötig. Ladezeiten steigen proportional

Komprimierung gilt für alle textbasierten Ressourcen: HTML, CSS, JavaScript, JSON, XML, SVG. Bilder (JPEG, PNG, WebP) sind bereits durch ihr Format komprimiert und nicht betroffen.

In der Praxis ist Brotli die bessere Wahl, wenn verfügbar. Aber Gzip ist völlig ausreichend — wichtig ist, dass die Komprimierung überhaupt aktiviert ist.

Wie Orilyt die Komprimierung bewertet

Test #01 ist binär. Orilyt überprüft den Content-Encoding-Header der Serverantwort:

1. Header enthält "br" oder "gzip" → Bewertung 100 — Komprimiert. Der Server macht seinen Job
2. Header fehlt oder ist leer → Bewertung 25 — Nicht komprimiert. Jeder Seitenaufruf überträgt unnötige Daten

Orilyt erkennt auch die Komprimierungsquelle. Wenn ein CDN wie Cloudflare oder QUIC.cloud vor der Website steht, übernimmt es oft die Komprimierung am Edge — selbst wenn der Origin-Server es nicht tut. Der Test unterscheidet zwischen CDN-Komprimierung und Origin-Komprimierung.

Warum die Komprimierung manchmal fehlt

Wenn Komprimierung so einfach ist, warum fehlt sie bei 15 % der Websites? Häufige Gründe:

1. Standard-Serverkonfiguration — manche Hosting-Anbieter liefern die Komprimierung deaktiviert aus. Der Website-Besitzer prüft es nie
2. Fehlkonfigurierte .htaccess — ein Plugin oder eine manuelle Bearbeitung hat die mod_deflate/mod_brotli-Regeln entfernt. Oder ein .htaccess-Reset hat sie gelöscht
3. Nginx ohne gzip on — Nginx hat die Komprimierung standardmäßig deaktiviert. Man muss explizit gzip on; zur Konfiguration hinzufügen
4. Reverse-Proxy-Konflikt — ein Load Balancer oder WAF entfernt den Content-Encoding-Header. Der Server komprimiert, aber der Besucher empfängt Rohtext

Die gute Nachricht: In 90 % der Fälle dauert die Korrektur weniger als 5 Minuten. Es ist entweder ein Häkchen im Hosting-Panel, eine Zeile in der .htaccess oder eine Plugin-Einstellung.

Komprimierung als Verkaufsargument

Für Freelancer und Agenturen ist ein Befund fehlender Komprimierung Gold wert. Er ist leicht zu erklären, spektakulär in der Wirkung und trivial zu beheben:

Im Orilyt-Bericht generiert Test #01 eine strukturierte FIA-Empfehlung:

1. Fakt: „Keine HTTP-Komprimierung erkannt — die Seite wird mit vollem Gewicht ausgeliefert (187 KB statt ~45 KB)"
2. Auswirkung: „Jeder Besucher lädt 4-mal mehr Daten herunter als nötig. Auf Mobilverbindungen erhöht das die Ladezeit um 1–3 Sekunden"
3. Aktion: „Gzip- oder Brotli-Komprimierung in der Serverkonfiguration aktivieren — geschätzte Verbesserung: 60–80 % Gewichtsreduzierung"

Eine Bewertung von 25/100 beim allerersten Test des Audits signalisiert sofort eine vernachlässigte Website. Es ist der Befund, der einen Kunden sagen lässt „wir brauchen Hilfe".

Die 5-Minuten-Korrektur, die alles verändert

Komprimierung ist die am leichtesten erreichbare Frucht in der Web-Performance. Keine Code-Änderungen, kein Redesign, keine komplexe Caching-Strategie — nur eine Servereinstellung, die jeden Seitentransfer um 60–80 % reduziert.

Test #01 von Orilyt erkennt es sofort. Die binäre Bewertung (100 oder 25) macht das Ergebnis glasklar — keine Mehrdeutigkeit.

Wenn Sie audit-basierte Angebote für Ihre Kunden erstellen, ist dies der Test, der sofortigen, greifbaren Wert demonstriert. Eine 5-Minuten-Korrektur mit messbarem Vorher/Nachher. So beginnt man ein Gespräch.