W3 Total Cache: Browser Decode Errors durch doppeltes Gzip beheben
Sporadische Browser Decode Errors nach der W3 Total Cache-Installation deuten oft nicht auf einen W3TC-Fehler hin – sondern auf doppelte Gzip-Komprimierung. Der Browser empfängt zweifach komprimierte Daten, scheitert beim Entpacken und zeigt eine Fehlermeldung. Hier ist die Diagnose und der Fix.
Das Symptom
Besucher sehen sporadisch eine Fehlermeldung wie:
Content Encoding Error
The page you are trying to view cannot be shown because it uses an invalid
or unsupported form of compression.
ERR_CONTENT_DECODING_FAILED
Das Verhalten ist intermittierend – manchmal lädt die Seite normal, manchmal schlägt sie fehl. Das ist ein typisches Zeichen für Race Conditions oder inkonsistente Cache-Zustände, wie sie bei doppelter Komprimierung entstehen können.
Die Ursache: Doppelte Gzip-Komprimierung
W3 Total Cache kann HTML, CSS und JavaScript gzip-komprimieren, bevor es sie im Cache ablegt. Wenn der Webserver (Nginx oder Apache) zusätzlich Gzip-Komprimierung aktiviert hat, wird die bereits komprimierte Antwort ein zweites Mal komprimiert. Der Content-Encoding: gzip-Header wird gesetzt – aber der Browser versucht, zweifach komprimierte Daten einfach zu entpacken und scheitert.
Prüfen, ob doppelte Komprimierung vorliegt:
curl -s -I -H "Accept-Encoding: gzip" https://example.com/ | grep -i content-encoding
curl -s --compressed https://example.com/ | file -
Wenn der zweite Befehl gzip compressed data ausgibt, obwohl curl bereits dekomprimiert hat, liegt doppelte Komprimierung vor.
Schritt 1: Gzip in W3 Total Cache deaktivieren
Im WordPress-Admin unter Leistung → Browser-Cache:
Die Optionen Aktiviere HTTP-Komprimierung (gzip) für HTML, CSS und JS deaktivieren und speichern.
Dasselbe unter Leistung → Seiten-Cache → Erweitert: Option Cache-Komprimierung deaktivieren.
Schritt 2: php-fpm Gzip-Konfiguration prüfen
Wenn trotz deaktiviertem W3TC-Gzip weiterhin ein Content-Encoding: gzip-Header gesendet wird, ist die Komprimierung in php-fpm oder dem Webserver konfiguriert. In der php-fpm-Konfiguration suchen:
grep -r "zlib.output_compression" /etc/php/
grep -r "output_compression" /etc/php-fpm.d/
Falls zlib.output_compression = On gefunden wird, auf Off setzen:
; In /etc/php/8.x/fpm/php.ini oder pool-Konfiguration
zlib.output_compression = Off
Danach php-fpm neu starten:
sudo systemctl restart php8.x-fpm
Schritt 3: Nginx/Apache Gzip-Konfiguration prüfen
Nginx: In der Server-Konfiguration prüfen, ob gzip on gesetzt ist:
grep -r "gzip" /etc/nginx/conf.d/
grep -r "gzip" /etc/nginx/sites-enabled/
Die sauberste Lösung: Nginx übernimmt die Gzip-Komprimierung, W3TC komprimiert nicht. In der Nginx-Konfiguration gzip on belassen, in W3TC alle Gzip-Optionen deaktivieren.
Apache: In der .htaccess oder Virtual-Host-Konfiguration nach mod_deflate-Direktiven suchen:
grep -r "mod_deflate|AddOutputFilter|DeflateCompressionLevel" /etc/apache2/
Die richtige Strategie: Entweder/oder
Die Grundregel bei Gzip und Caching: Komprimierung darf nur an einer Stelle stattfinden.
Option A – Webserver komprimiert: Gzip in Nginx/Apache aktiviert, in W3TC deaktiviert. Der Webserver komprimiert dynamisch. Vorteil: Einheitliche Konfiguration.
Option B – W3TC komprimiert: Gzip in W3TC aktiviert, im Webserver deaktiviert. W3TC legt komprimierte Cache-Dateien ab. Vorteil: Weniger CPU-Last pro Request, da aus dem Cache bedient.
Beide Optionen sind korrekt – wichtig ist nur, dass nie beide gleichzeitig aktiv sind.
Cache leeren nach der Änderung
Nach der Konfigurationsänderung unbedingt alle Caches leeren:
wp cache flush
wp w3-total-cache flush all
Und ggf. den CDN-Cache (Cloudflare etc.) purgen, damit keine doppelt komprimierten Dateien noch aus dem Edge-Cache ausgeliefert werden.
Fazit
Browser Decode Errors in Verbindung mit W3 Total Cache sind fast immer auf doppelte Gzip-Komprimierung zurückzuführen. Die Lösung: Gzip entweder im Webserver oder in W3TC aktivieren – niemals in beiden gleichzeitig. Besonders zlib.output_compression in php-fpm wird oft übersehen und ist ein häufiger Kandidat für dieses Problem.


