Post 1496
Wordpress

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-CacheErweitert: 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.