WordPress – Caching muss sein

WordPress rumpelt und holpert durch die Landschaft, wenn man dem Ganzen keinen Einhalt gebietet. Das Zauberwort heißt hier Caching. Und das lohnt sich. Wie man das Ganze realisiert, muss man immer selbst entscheiden. Ich bin jedenfalls der Meinung, dass man das Ganze nicht immer ausschließlich mit Plugins tun muss, mit denen man unter Umständen WordPress aufbohrt und / oder sich Probleme ins Haus holt. Ich regle mein Caching ganz anders. Und das möchte ich mal eben aufschreiben.

# Deflate Compression by MimeType
<IfModule mod_deflate.c>
 <FilesMatch "\.(js|jpg|jpeg|gif|png|css)$">
 SetOutputFilter DEFLATE
 </FilesMatch>
</IfModule>

## EXPIRES CACHING ##
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType text/css "access 1 month"
ExpiresByType application/pdf "access 1 month"
ExpiresByType text/x-javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
ExpiresByType image/x-icon "access 1 year"
ExpiresDefault "access plus 2 days"
</IfModule>
## EXPIRES CACHING ##

<IfModule mod_headers.c>
Header append Cache-Control "public"
Header append Vary Accept-Encoding
Header set Connection keep-alive
Header unset ETag
FileETag None
</IfModule>

Jetzt kann man das halten, wie man will. Ich jedenfalls arbeite mit einer .htaccess, was das Caching betrifft. Dort kann ich wunderbar einstellen, was wann abläuft. So ist es unwahrscheinlich, dass sich Bilder ändern, weshalb erst nach einem Jahr der Browser schauen soll, ob das Bild erneuert wurde. Bei Texten ist das schon anders. Die können erweitert werden. Auch finden Korrekturen statt, die eventuell die im Cache vorhandene Version überschreiben. Und all das. Die Einstellungen sind dann hier erklärt.

Dazu ist es empfehlenswert, die über dem Modul „mod_expires.c“ befindliche Kompression einzubauen. Es ist immer sinnvoll, die Datenmenge so gering wie möglich zu halten. So werden hier im Beispiel JavaScript- und CSS-Dateien ebenso komprimiert wie Bilder. Auch hierzu ist eine Dokumentation erhältlich. Man kann sicherlich noch mehr einstellen. Der ganze obige Block ist ja einfach nur ein Beispiel. Und am Ende ist es doch so, dass man viel lesen kann, was man so als „ultimative .htaccess“ ansehen kann.

Na klar, all das und noch viel mehr machen auch Caching Plugins. Davon werden immer wieder welche beschrieben. Die Frage ist halt, ob man das tatsächlich immer mit Plugins machen muss. Es heißt ja immer, dass man immer so viele Plugins wie nötig, aber so wenige wie möglich einsetzen soll. Denn jedes Plugin kann ein Loch in die Wand von WordPress bohren. Außerdem bedeutet jedes Plugin mehr einen erhöhten Verwaltungsaufwand. Hier muss man einfach abschätzen, ob das so sein muss.

Es gibt auch Caching Plugins, die durchaus von mancher Seite her als Sicherheitsrisiko bezeichnet werden. Und diverse Caching Plugins arbeiten auch mit externen Cloud Diensten zusammen. Ich denke daher, dass man sich genau überlegen sollte, ob man denn tatsächlich zur Steigerung der Leistung des eigenen Blogs ein zusätzliches Plugin installiert werden muss. Ich wäre skeptisch. Aber am Ende ist das Alles eine Sache des persönlichen Geschmacks.

2 Replies to “WordPress – Caching muss sein”

    1. Hallo Thomas,

      ich komprimiere JavaScript und CSS mittels .htaccess und dem #Deflate-Bereich, siehe Artikel. Für HTML habe ich noch nichts richtiges gefunden und arbeite da mit „Fast Velocity Minify“.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert