Viele Leute erachten Caching als den ultimativen Heilsbringer, wenn es um die Performance einer Website geht.

Caching-Plugins

Eigentlich ist WordPress für die meisten Websites performant genug. Wenn man allerdings ein komplexes Theme und viele Plugins installiert hat, dann wird es langsamer. Das Gleiche passiert, wenn die Website populärer wird. Um das zu Problem zu lösen gibt es eine Reihe an Caching-Plugins:

…um nur einige zu nennen. Diese Plugins erweitern WordPress um Caching: Weil WordPress durch 1000 Plugins langsamer geworden ist fügt man nun das 1001. Plugin hinzu um es wieder schneller zu machen. Die Idee ist haarsträubend und jeder Mensch mit einem Funken gesunden Menschenverstand erkennt sofort, dass das nicht funktionieren kann – aber Überraschung: Doch, das geht. Zumindest ein bisschen. Es kann einem spontan und ohne viel Aufwand schon mal ein paar ordentliche Prozent Performance schenken. Allerdings ist der Konfigurationsaufwand nicht zu unterschätzen. Zwar laufen viele Caching-Plugins ohne komplizierte Konfiguration, so dass auch Anfänger es zumindest “zum Laufen bekommen”, aber je mehr man erreichen will, desto mehr muss man sich hineinknieen und desto mehr Ahnung braucht man dazu.

Cachen vor WordPress

Wenn man sich mit den Details (insbesondere von W3 Total Cache) auseinandersetzt, dann merkt man aber schnell, dass man den größten Performancegewinn erreicht, wenn der Cache nicht von WordPress ausgeliefert wird, sondern direkt vom Webserver oder gar einem Proxy. Denkt man den Gedanken zu Ende, dann ist klar, dass das der Webserver (oder ein Proxy) auch ohne Caching-Plugin kann.

Ein Proxy wäre Varnish, aber wenn man Nginx als Webserver nutzt (so wie wir bei Taquiri), dann braucht man keinen Proxy vor der Website, denn der Webserver ist performant genug und kann WordPress von Haus aus cachen.

Praktisch geht es dabei darum, dass man dem Webserver so wenig Arbeit wie möglich macht. In einem Standard-Setup von WordPress mit einem “preforking” Apache mit mod_php ist das nicht der Fall. Für jeden Request (nicht nur der Aufruf der Seite, sondern auch für jedes der 50 Bilder auf der Seite) springt ein Webserver-Prozess ein, welcher sich exklusiv um diesen Request kümmert. Dieser Prozess hat das PHP schon “eingebaut” und ist dementprechend “fett”.

Bei Nginx mit fast-cgi ist der Webserver “schmal”. Nur für den Aubau der Seite konsultiert er das (externe) PHP. Die 50 Bilder (und noch weitere Requests) werden von einem Webserver-Prozess abgehandelt. Das nimmt viel Last von der Hardware. Für die Seite wird in dieser Konstellation allerdings immernoch WordPress samt PHP aufgerufen, teure Datenbankverbindungen hergestellt, etc. Das kann man allerdings auch größtenteils verhindern.

Nginxs fastcgi-Schnittstelle besetzt einen Cache, welcher die von WordPress/PHP zurückgegebenen Inhalte cachen kann. Solange der Benutzer nicht eingeloggt ist bekommt er also nicht den aktuellen Status der Website zu sehen, sondern unter Umständen den, wie er vor 5 Minuten war.

Statt jedes mal immer und immer wieder…

  • die gleiche komplizierte Software anzuschmeißen
  • die gleichen Inhalte aus der Datenbank zu holen
  • die gleichen Filter drüberlaufen zu lassen
  • die gleichen Methoden anzuwenden
  • und auch immer wieder zum gleichen Ergebnis zu kommen – vielleicht mehrmals pro Sekunde

…merkt man sich das Ergebnis für kurze Zeit und liefert dieses Ergebnis direkt aus. Dadurch geht die Last des Servers auf ein Bruchteil zurück und die Website wird auch viel schneller an den Benutzer ausgeliefert.

Im Gegensatz dazu würde ein “WordPress-interner” Cache jedesmal PHP und WordPress samt starten, damit WordPress die gecachte Seite ausliefern kann. Ein solches WordPress kann zwar schnell rennen wie ein Hase, aber der Igel ist immer schon vorher da.