Da der Server, auf dem dieser Blog läuft, nicht von der schnellsten Sorte ist und außerdem nur an einer 16MBit ADSL-Leitung hängt, hab ich mich nach Möglichkeiten umgesehen die Server- und Netzlast zu reduzieren. Da auf dem Server nur der Blog öffentlich verfügbar ist hab ich mich auf WordPress-Plugins beschränkt um das Problem zu lösen und mich für Hyper-Cache entschieden, da alle anderen, wie z.B. WP-Cache, keine gepackte Übertragung (gzip) unterstützen und dadurch die Netzwerklast nicht mindern können.
Die Installation ist einfach und kann automatisch in WordPress selbst erfolgen. Die Einstellungen des Plugins sind (fast) ausreichend erklärt. Bei ein paar Punkten gibts aber durchaus was zu sagen:
- Expire a cached page after
- Die gecacheten Inhalte verfallen nach x Minuten und werden dann bei Bedarf neu erstellt. Da das Entfernen des Caches korrekt funkioniert (siehe “What cached pages to delete on events”), sollte der Wert bei 0 stehen (siehe weiter unten).
- Autoclean every
- Nach x Minuten werden alle Cache-Einträge entfernt. Wie beim ersten Punkt sollte das auf 0 Stehen (siehe weiter unten)
- What cached pages to delete on events
- Hier traue ich mich nichts anderes als all einzustellen. Ich nehme lieber in Kauf, einen Cache bei Inhaltsänderungen ein mal zu oft zu entfernen, als alte Inhalte auszuliefern. So lange man nicht ständig im Adminbereich rumwuselt, ist das ok. Andere Einstellungen habe ich aber noch nicht getestet.
- Optimize HTML
- Entfernt die Leerzeichen aus dem HTML. Das spart ein winziges bisschen Platz und verringert dadurch die Netzwerklast, allerdings bremst das die Erstellung einer Seite extrem aus (siehe Benchmark)
- Gzip compression
- Packt die Inhalte vor dem Ausliefern mit gzip und spart somit viel Netzwerklast. Da gzip sehr schnell ist, ist die Serverlast im Gegenzug kaum spührbar
Im praktischen Einsatz zeigen sich dann mit unterschiedlichen Einstellungen folgende Werte:
| WordPress ohne Cache | Hypercache | Hypercache + gzip | Hypercache + gzip + Optimize HTML | |
|---|---|---|---|---|
| Seitenaufruf (der erste) | 2.7s | 3.1s | 3.3s | 5.2s |
| Seitenaufruf (alle weiteren) | 2.7s | 0.6s | 0.5s | 0.5s |
| Übertragene Daten | 45.0K | 45.1K | 15.0K | 14.7K |
Gemessen mit YSlow + Firebug
Die Kosten für das Erstellen des Caches an sich sind zwar hoch, aber nicht extrem. Die halbe Sekunde mehr fällt bei den bisher nötigen 2,7 Sekunden kaum auf. Die Außname bildet hier das “Optimize HTML”, was ich aus dem Grund direkt abgeschalten habe. Dieser Zeitverlust ist einfach zu gravierend, denn ab und zu verfällt der Cache ja schon und 5 Sekunden sind eine verdammt lange Zeit zum Warten auf eine Seite. Der Nutzen durch das Ausliefern von bereits gecachten Seiten lässt sich bei allen Cache-Einstellungen sehen. Das ist immerhin über das Vierfache, was hier an Geschwindigkeit rausgeholt werden kann.
Der Erfolg von gzip ist auch ziemlich gut, denn immerhin werden zwei Drittel an Daten gespart. Aber bedenkt man, dass hier zusätzlich noch rund 95K an CSS, JS und Bildern übertragen werden, relativiert sich das ein bisschen. Der Zusatznutzen beim Platzverbrauch durch das “Optimize HTML” zwar ok, aber die oben genannten Nachteile sind einfach zu schwerwiegend.
Der Verfall der Cache-Inhalte funktioniert an sich sehr gut und ich konnte keinerlei Fehler feststellen. Dadurch sind die oben aufgeführten Einstellungen zum Verfall von Cache-Inhalten meines Erachtens nicht nötig. Der Nachteil bei verfallenem Cache währe in meinem Fall, dass der Benutzer 2,1 Sekunden länger auf die Seite warten muss, als nötig. Und das, finde ich, ist eine sehr lange Zeit im Netz.
Fazit
Bisher konnte ich in den zwei Wochen, wo ich es Benutze, keine Nachteile erkennen und die Vorteile liegen auf der Hand. Ich kann den Einsatz des Plugins nur empfehlen.
Nachtrag zu WP-Cache
Noch ein guter Grund, WP-Cache, WP-Cache2 bzw. WP-Super-Cache nicht zu verwenden ist, dass man php-save deaktiviert muss um alle Funktionen nutzen zu können. Sicherheit opfere ich extrem ungern. Egal für was.