Caching in WordPress Jenseits des Optimierungs-Wahns – Wie man WordPress wirklich schneller macht

16.12.2009

(von Guido Mühlwitz) Nachdem Google in seinen Webmaster Tools das neue Feature „Website-Leistung“ freigeben hat, und klar ist, dass die Geschwindigkeit, mit der eine Webseite abgerufen wird, zukünftig einen Ranking-Faktor darstellt, hat ein Optimierungs-Wahn bei den WordPress-Blog-Betreibern eingesetzt. Es haben so gut wie alle mir bekannten Blogs von Google amtlich attestiert bekommen, dass sie zu langsam sind! Dies wird über kurz oder lang natürlich Auswirkungen auf die Besucherzahlen haben, und logischerweise muss nun versucht werden, diesem Umstand entgegenzuwirken.

Für die Optimierung der Blogs werden derzeit (auch von mir selbst) eine ganze Menge an Tutorials veröffentlicht , die sich mit Header-Optimierung und Ähnlichem beschäftigen. Es gibt auch Ansatzpunkte zur Optimierung von Bildern und dem Minify von JavaScript und CSS. Die Diskussion an sich ist schon alt, nimmt aber derzeit rasant an Fahrt auf. Logischerweise schaut sich kein Blog-Betreiber teilnahmslos mit an, wie er in den Suchergebnissen von Google nach hinten durchgereicht wird.

Viele Mutmaßungen, wenig Konkretes

Geschwindigkeits-Verlaufskurve einer Website in den Google Webmaster Tools

In den Webmaster Tools zeigt Google seit Neuestem an, welche Geschwindigkeit für eine Website gemessen wurde. Diese hier hat (zumindest laut Google) einigen Optimierungsbedarf.

Aufgrund meiner Beobachtungen bei Twitter und in der Blogosphäre macht sich jedoch eine gewisse Hilflosigkeit breit, die zum Beispiel auch in den Kommentaren dieses Blogbeitrags nachverfolgt werden kann. Die Anzahl der Mutmaßungen ist fast ebenso hoch wie die möglichen Lösungsvorschläge, allein: Ob eine der Maßnahmen zum Erfolg führen wird, kann trotz Tools wie Page Speed oder YSlow niemand sagen oder garantieren.

Nie habe ich das Sprichwort „Mit Kanonen auf Spatzen schießen“ so gerne angewendet, wie im Moment. Die derzeitige Diskussion in den Blogs erinnert mich durchaus an die anhaltende Diskussion um die Mikro-Optimierung von PHP (Was ist schneller: „echo“ oder „print“?). Einige durchaus sehr einfache Maßnahmen haben viele der Blogs nicht im Einsatz, und die beiden damit verbundenen WordPress-Plugins sind durchaus sinnvoll und ihr Nutzen nachvollziehbar (siehe weiter unten).

Es ist nämlich nicht so, das es für WordPress keine Caching-Plugins gäbe, im Gegenteil! Und der Nutzen dieser Plugins ist um einiges größer als die derzeitig propagierten Optimierungen, die hauptsächlich von YSlow oder Page Speed vorgeschlagen werden. Die Grundlage jedes Blogs ist die dahinterliegende HTML-Seite. Je schneller diese ausgeliefert wird, desto schneller ist der Blog. Die Renderzeit einer Seite ist in WordPress proportional zu der Anzahl der Plugins, die installiert worden sind.

Fakt: unsichtbare Bremsen für WordPress

Verführerisches Plugin-Directory... Plugins können im Hintergrund eine erhebliche Bremse sein.

Viele mögen jetzt sagen, dass sie ja zum Beispiel nicht auf jeder Seite ein Youtube-Video eingebunden haben, ergo das Plugin ja auch nicht auf jeder Seite ausgeführt wird. Diese Annahme ist falsch. Installiere ich in WordPress 20 Plugins, die allesamt den Content beeinflussen, dann werden bei jedem Seitenaufruf auch alle 20 Plugins ausgeführt. In unserem Beispiel wird das Youtube-Plugin also auch dann ausgeführt, wenn die Seite kein Youtube-Video enthält.

Je mehr Plugins ich demnach installiere, desto mehr Aufrufe pro Seite verarbeitet WordPress. Das ganze Dilemma wird dann klar, wenn man davon ausgeht, dass ein Plugin nicht nur einen Filter auf den Content anwendet, sondern parallel dazu auch Settings aus der Datenbank auslesen muss. Man könnte jetzt anmerken, dass logischerweise die Plugins erst dann die Datenbank verwenden müssen, wenn sie auch wirklich verwendet werden. Dies ist soweit richtig, setzt aber auch voraus, dass der jeweilige Programmierer überhaupt so weit mitgedacht hat.

Rettung in der Not: Caching-Plugins

Insofern ist die einfachste und notwendigste Optimierung eines Blogs der Einsatz eines Caching-Plugins. Derzeit sind zwei „Standard-Plugins“ mit unterschiedlichen Ansätzen verfügbar, deren Notwendigkeit von Blog zu Blog unterschiedlich ist.

WP Super Cache

Der WP Super Cache basiert auf dem einfachen Konzept, dass es WordPress-Seiten als statisches HTML auf der Festplatte ablegt, und diese Seiten ausliefert anstatt sie bei jedem Seitenaufruf von WordPress erneut rendern zu lassen. Logischerweise hilft das nur bedingt: Auf einem Blog mit vielen Kommentaren bzw. vielen Stammlesern würde die Seite trotzdem bei jedem neuen Kommentar neu gerendert werden. Bekommt die Seite jedoch nicht allzu viel Kommentare, ist dieses System optimal. Das gilt ebenso bei einem Einsatz von WordPress als CMS.

DB Cache Reloaded

DB Cache Reloaded behauptet von sich selbst, das schnellste WordPress-Caching-Plugin zu sein, wahrscheinlich unbeachtet der Tatsache, dass Dateioperationen im Optimierungsumfeld als sehr „teuer“ gehandelt werden. Das Plugin legt keine statischen HTML-Seiten an, sondern cached die Datenbankabfragen von WordPress an sich. Vorteil ist, dass auch die Teile von WordPress gecached werden, die WP Super Cache nicht zwischenspeichern kann. Während WP Super Cache stets eine gesamte Seite neu rendern muss um eine statische Version anzulegen, braucht DB Cache Reloaded nur Teile der Seite neu zu berechnen.

Fazit

Welches Caching-Plugin auf einem Blog verwendet werden sollte, hängt stark von den Besucherzahlen und der Art des Blogs ab. Während in manchen Fällen eines der Plugins ausreicht, gibt es auch Beispiele, in denen beide Plugins parallel betrieben zu einer nachhaltigen Verbesserung der Ladezeiten geführt haben. Dass ein solches Plugin in Blogs mit hohen Seitenabrufzahlen gehört, dürfte nun klar sein. Welches der Plugins eingesetzt werden muss, muss im Einzelfall getestet werden.

Über den Autor

Guido Mühlwitz ist freier Webworker und entwickelt seit über 15 Jahren Internet-Anwendungen. In seinem Blog berichtet er regelmäßig über aktuelle WordPress-Themen. Open Source Web Applications wie Drupal, CakePHP und ModX gehören regelmäßig zum Themenbereich seiner Veröffentlichungen.

wordpress ist gelistet auf t3n.de/opensource!

Weitere Artikel zu Google und WordPress

22 Antworten

von Caching in WordPress: Jenseits des Optim… 16.12.2009 (10:55Uhr) 1.

[...] post: Caching in WordPress: Jenseits des Optimierungs-Wahns – Wie man WordPress wirklich schneller macht... Comments0 Leave a Reply Click here to cancel [...]
von Caching in WordPress: Jenseits des Optim… 16.12.2009 (11:00Uhr) 2.

[...] In: Wordpress plugins 16 Dec 2009 Viele mögen jetzt sagen, dass sie ja zum Beispiel nicht auf jeder Seite ein Youtube-Video eingebunden haben, ergo das Plugin ja auch nicht auf jeder Seite ausgeführt wird. Diese Annahme ist falsch. Installiere ich in WordPress 20 Plugins, die allesamt den Content beeinflussen, dann werden bei jedem Seitenaufruf auch alle 20 Plugins ausgeführt. In unserem Beispiel wird das Youtube-Plugin also auch dann ausgeführt, wenn die Seite kein Youtube-Video enthält. Je mehr Plugins ich demnach installiere, desto mehr Aufrufe pro Seite verarbeitet WordPress. Das ganze Dilemma wird dann klar wenn man davon ausgeht, dass ein Plugin nicht nur einen Filter auf den Content anwendet, sondern parallel dazu auch Settings aus der Datenbank auslesen muss. Man könnte jetzt anmerken, dass logischerweise die Plugins erst dann die Datenbank verwenden müssen, wenn sie auch wirklich verwendet werden. Dies ist soweit richtig, setzt aber auch voraus, dass der jeweilige Programmierer überhaupt so weit mitgedacht hat Go to Source [...]
von Gastbeitrag bei T3N: Caching in WordPres… 16.12.2009 (11:29Uhr) 3.

[...] ist der Titel “Jenseits des Optimierungs-Wahns – Wie man WordPress wirklich schneller macht” etwas reißerisch, zumal die vorgeschlagenen Lösungen eigentlich jedem Blog-Betreiber [...]
von gutu 16.12.2009 (11:43Uhr) 4.

Kann man die beiden Plugins "WP Super Cache" und "DB Cache Reloaded" parallel laufen lassen?
von Guido Muehlwitz 16.12.2009 (11:46Uhr) 5.

Klar, ob es Sinn macht ist eine andere Frage :) Du musst mit YSlow oder Page Speed die Ladezeiten vergleichen. Für ein "normales Blog" reicht in der Regel eins der beiden. Welches das ist hängt wiederum von der Art und der Anzahl der Plugins ab - also heißt es: ausprobieren! :)
von Nils 16.12.2009 (12:06Uhr) 6.

Mit WP Super Cache habe ich auf meinem Blog eher schlechte Erfahrungen gemacht. DB Cache Reloadet hört sich interessant an - werde ich die Tage mal testen. Danke für den Hinweis ;)
von Guido Muehlwitz 16.12.2009 (12:19Uhr) 7.

Es gibt Blogs, die laufen ohne WP Super Cache schneller als mit, deshalb: ausprobieren! :) Es ist alles eine Frage der Benutzerzahlen und der installierten Plugins :)
von Frank 16.12.2009 (12:29Uhr) 8.

Aus meiner Erfahrung sollten nur User mit derartigen Cache-Plugins spielen, die einiges an Hintergrundwissen mitbringen und die viele andere Optimierungen schon getan haben, sei es Themes, Plugins und Webspace. Außerdem meine ich, dass die Aussage "langsam" der Webmaster Tools vor allem externe Dienste meint und diese auch in den Hinweisen listet, die DNS dort können enorm die Site bremsen und hier sehe ich bei vielen Plugins ein großes Potenzial der Optimierung. Jeder Admin sollte ich überlegen, ob er denn jeden externen Service einbinden muss und wie viele Sites man pingt.
von Monika.TS 16.12.2009 (13:29Uhr) 9.

Frank ich gebe Dir ja recht, doch die Tools listen Sachen auf, die haarsträubend sind. Eine print.css in die normale style.css zu integrieren ist schlussendlich langsamer als ein eigenes Style.

++++++++++
zum Artikel: der gefühlte 987654789Millionste dieser Tage, der Tools, Plugins aufzählt, aber keiner schreibt wies wirklich geht.

Ich weiß nicht wie es andern geht, aber ich habe genug E-mails derzeit: ich komm mit dem Plugin nicht zu recht, ich mit jenem ---Hilfe!!!

All die dargestellten CachePlugins brauchen jemand, der sich 100% auskennt, sonst killt man 1. wichtige Dinge auf seinem Blog,
oder wird 2. extrem langsamer

die Pluginautoren setzen Wissen und Serverkonfigurationen voraus, die mehr als die Hälfte der Leut einfach nicht haben.

aber all diese Artikel tun eines: sie schüren Angst

lg
Monika
von Frank 16.12.2009 (13:40Uhr) 10.

@Monika: das ist ja was ich meine; die Tools können das Wissen nicht ersetzen, sie können nur unterstützend helfen.

Zu den Plugins: genau, es sollten User diese Plugins einstellen, die es verstehen und die auf die versch. Bereiche Einfluss nehmen können. Sicher kann Super Cache helfen, aber wenn dann alles statisch ist, sind auch viele unzufrieden - sie haben sich meist nicht mit dem Plugin auseinander gesetzt. Der Webspace kann je nach Anbieter oft viel mehr.

Aber ich meine trotzdem, dass viele Sites einfach zu viele externe Dienste rein holen; zumindest im Vergleich von Mehrwert und Speed der Site
von Peter 16.12.2009 (14:05Uhr) 11.

Also wenn es ums Caching bei WordPress geht, ist W3 Total Cache meine Wahl. Effektiver als durch dieses Plugin geht es fast nicht mehr.
von sergej.mueller 16.12.2009 (14:17Uhr) 12.

Kann ich auch bestätigen: Man soll nicht gleich Cache-Plugins einbinden und aktivieren, vielmehr erst prüfen, ob der "Fehler" für die Langsamkeit des Blogs nicht doch woanders liegt. Es gibt zig Ursachen, warum Blogseiten träge sind, da sind statische Inhalte nicht immer eine bessere Wahl. Es lohnt sich fast immer nach der Ursache zu suchen, beim Provider nachfragen, meinen Blog lesen, wo ich permanent Tipps zur Performance-Steigerung gebe.
von delicious Links: 16. December 2009 17.12.2009 (00:01Uhr) 13.

[...] Caching in WordPress: Jenseits des Optimierungs-Wahns – Wie man WordPress wirklich schneller macht... Viele mögen jetzt sagen, dass sie ja zum Beispiel nicht auf jeder Seite ein Youtube-Video eingebunden haben, ergo das Plugin ja auch nicht auf jeder Seite ausgeführt wird. Diese Annahme ist falsch. Installiere ich in WordPress 20 Plugins, die allesamt den Content beeinflussen, dann werden bei jedem Seitenaufruf auch alle 20 Plugins ausgeführt. In unserem Beispiel wird das Youtube-Plugin also auch dann ausgeführt, wenn die Seite kein Youtube-Video enthält. Je mehr Plugins ich demnach installiere, desto mehr Aufrufe pro Seite verarbeitet WordPress. Das ganze Dilemma wird dann klar wenn man davon ausgeht, dass ein Plugin nicht nur einen Filter auf den Content anwendet, sondern parallel dazu auch Settings aus der Datenbank auslesen muss. Man könnte jetzt anmerken, dass logischerweise die Plugins erst dann die Datenbank verwenden müssen, wenn sie auch wirklich verwendet werden. Dies ist soweit richtig, setzt aber auch voraus, dass der jeweilige Programmierer überhaupt so weit mitgedacht hat Tags: wordpress speed cache caching plugins plugin [...]
von aba 17.12.2009 (00:35Uhr) 14.

ich kann peter (#9) nur zustimmen: w3 total cache ist eine feine sache, zumal es auch cdn unterstuetzt.
von sergej.mueller 17.12.2009 (09:21Uhr) 15.

@aba
Auch ein CDN bringt nichts, wenn jedes Plugin auf eigenes JS-Framework aufbaut und es in jede Blogseite "hard" einbindet.
von Hannes 17.12.2009 (11:46Uhr) 16.

Kann nur zustimmen, meiner Erfahrung nach ist zur Zeit W3TC das Caching Tool der Wahl, und zwar nicht nur in der Not - einfach zu handhaben und sehr gut skalierbar auf Grund der vielfältigen (aber nicht überladenen) Konfigurations-Möglichkeiten und verschiedenen Caching Backends (APC, Memcached, DB, File ...) Und der Entwickler reagiert auch recht fix auf Anfragen, sehr schön! War schon n bisschen schockiert das es in der Auflistung hier gefehlt hat.

Des weiteren ist es meiner Erfahrung nach auch nicht verkehrt sich ab und zu mal an zu sehen was Wordpress und diverse Plugins der Meinung sind in den header / footer werfen zu müssen, so lassen sich zum Beispiel eingebundene Scripts mit 'remove_action('wp_head', 'wp_print_head_scripts',9,0);' in der functions.php des Templates entfernen (wenn man zum Beispiel wie ich lieber alle scripts minified im Footer und die JS Libary über google einbindet).

LG
von dongorgon 17.12.2009 (17:14Uhr) 17.

^^ So sieht's einfach mal aus. Alles lame ausser Mutti + W3 Totalcache ;-)

Kann Hans da nur voll zustimmen
von aba 17.12.2009 (20:32Uhr) 18.

@sergej.
voellig richtig. dennoch finde ich einerseits die option natuerlich gut.
aber du hast recht: die ursache ist damit nicht "bekaempft". mir graut es immer, wenn ich mir mit z.b. page analyze anschaue, wieviele zig javascript und kram und zeug geladen werden, die teilweise ja nichtmal auf allen seiten benoetigt werden...
von Hannes 18.12.2009 (10:21Uhr) 19.

@aba
wie gesagt, lässt sich ja alles mit Hilfe von 'remove_action('wp_head', 'wp_print_head_scripts',9,0);' entfernen, und falls die scripts a andere hooks gehangen werden muss man leider n dump des action stacks machen und dann mit trial and error vorgehen... ärgerlich ist es nur wenn Plugins Sachen nicht über die hooks einbinden sondern über dne Output Buffer, son Plugin würde aber auch sofoer deaktiviert gehören ;)
von domingos 18.12.2009 (13:43Uhr) 20.

Überflüssige Pugins abschalten, Datenbank regelmäßig optimieren, überflüssige Entwürfe löschen, WP-eigenen Cache einschalten, Fotos webgerecht komprimieren, Datenbank-eigenen Cache aktvieren, man kann alles mögliche tun, ob das für ein prvates Blog mit 30 Bescuhern pro Tag sinnvoll ist, ist aber eine andere Frage.
von Google-Feature Page Speed | Internet und… 18.12.2009 (18:38Uhr) 21.

[...] t3n mit einem Post über unsichtbare Speed-Bremsen in CMS [...]
von [Linktipps] Jede Menge Tipps für ei… 10.01.2010 (18:02Uhr) 22.

[...] gunnart oder auch auf t3n wurden die in Wordpress eingebaute Caching Funktion oder aber auch andere Cache-Plugins [...]