Wenn WordPress immer langsamer wird

3,5 Sekunden – so lange dauerte es zuletzt, bis eine Seite meines Blogs erzeugt und ausgeliefert war, zggl. CSS-, JavaScript- und Bild-Dateien. Ich habe das erst gar nicht bemerkt, da ich die letzten Wochen sehr blogfaul gewesen bin. Der schlussendliche Augenöffner war ein Blick in die Google Webmaster Tools. Hier in der Crawling-Statistik ist klar abzulesen, dass gerade in den letzten Wochen und Monaten die Zeit, die der Webserver zur Auslieferung einer Seite meines WordPress Blogs immer größer wurde, im Schnitt rund 2.7 Sekunden, zuletzt bis zu 3.8 Sekunden:

Crawling-Statistik in den Google Webmaster Tools

Eine so lahme Website ist nicht nur für Besucher nervig. Nein, die Auslieferungsgeschwindigkeit wird bei Google womöglich in 2010 ein Ranking-Faktor werden. Viele vermuten bereits seit einiger Zeit, dass dies schon aktuell der Fall ist und schnellere Seiten einen Vorteil in den Rankings haben. Der Eindruck mag aber auch nur daher rühren, dass die gut gerankten Seiten eben auch oft gut besucht sind, von größeren Firmen und Projekten stammen und hier einfach mehr und besser an der Infrastruktur gearbeitet wird.

Auf der Suche nach den Ursachen für die wachsende Zähigkeit konnte ich den Server selbst klar ausschließen. Mein Root-Server hat kaum Last, ist gut konfiguriert und hat mit Dual-Quadcores und 8 GB RAM reichlich Leistungsreserven. Schnell fand ich im Netz Frank Bültges kleines Debug Queries Plugin für WordPress. Aktiviert fügt es am Seitenende eine Auflistung der für die Seitengenerierung erzeugten Datenbank-Abfragen durch und gibt aus, wo diese abgesetzt wurden. So war schnell herausgefunden, dass eine einzelne SQL-Abfrage des Popular Post Moduls alleine 3 Sekunden dauerte. Die Abfrage habe ich händisch nochmal in MySQL laufen lassen und die 3 Sekunden Laufzeit wurden hier bestätigt. Ein EXPLAIN förderte zudem ad hoc kein Verbesserungspotenzial im Aufbau der Abfrage zutage, das ich „mal eben“ hätte nutzen können.

Da ich noch eine alte 1.3er Version einsetzte, die aktuelle 1.5.1 aber nur über den Zwischenschritt der 1.4.6 upgedatet werden soll, entschloss ich mich kurzerhand das Modul zunächst zu deaktivieren und komplett zu deinstallieren und danach die aktuelle Version zu installieren.

Und siehe da, nun braucht es keine 3,5 Sekunden mehr eine Blog-Seite zu erzeugen, sondern nur noch 0,8 Sekunden! Persönlich empfinde ich das nicht als berauschend schnell, aber so ist WordPress nunmal.

Wenn eure Seiten auch immer langsamer werden, lohnt sich ggf. auch ein Blick auf die Datenbankabfragen – neben diversen anderen Punkten, die ich im Vorfeld schon ausschließen konnte.

Update

Mittlerweile habe ich hier W3 Total Cache laufen. Die Auslieferung des HTML Quelltextes dauert damit – wenn die Seite im Cache liegt – aktuell nur noch rund 70 Millisekunden. Als Cache kann dabei sowohl die Festplatte / der Webspace genutzt werden, als auch APC und Memcache, wenn vorhanden. Da das Blog auf einem meiner eigenen Server läuft, setze ich APC und habe dabei ein Auge auf die Größe des APC Cache. Zusätzlich unterstützt W3 Total Cache die Minifizierung und Komprimierung von CSS- und JS-Dateien mit diversen Optionen und bringt selbst Support für CDNs (Content Delivery Networks) mit.

Kommentare (8)

  1. Danke für den Tipp! Auch bei mir hat wohl Popular Post deutlich auf die Bremse gedrückt. Ich habe das Update gemacht und jetzt sieht das wieder besser aus. Hat nach den letzten MEssungen etwa eine Sekunde ausgemacht.

  2. „Viele vermuten bereits seit einiger Zeit, dass dies schon aktuell der Fall ist und schnellere Seiten einen Vorteil in den Rankings haben“

    Es heisst – „Schnelle Ladezeiten“ sollen einen positiven einfluss haben – „Langsame Ladezeiten“ aber sich nicht negwairv auswirken. Ist die offizielle stellungsnahme von Google .. (Matt etc..)

  3. Warum setzt ein Drupal Entwickler wie Du eigentlich auf WordPress? Sicher wer nicht eh mit Drupal arbeitet oder sehr spezielle Vorgaben an seinen Blog hat wird sicher eher mit wp glücklich, aber was hat bei Dir den Ausschlag gegeben?

    … Oder warst Du einfach zu beschäftigt um umzusteigen? ;)

  4. Ich bin da nicht dogmatisch veranlagt, muss ich zugeben. Anders als ursprünglich geplant mache ich derzeit auch nicht nur in Drupal, sondern auch allgemein in PHP, pflege demnächst wieder ein paar alte Java-Anwendungen von mir und werde dieses Jahr wohl noch auf dem iPhone-Sektor aktiv.

    Was den Blog angeht habe ich einfach bislang den Aufwand gescheut diesen Blog auf Drupal umzustellen. Angetestet hatte ich den Import zu D5-Zeiten schonmal. Wenn ich aber sehe, dass auch meine gewerbliche Seite extremst drunter leidet, dass ich für mich selbst zu wenig Zeit freischaufle, dann ist dieser Blog auch eher auf Platz 3 der Prioritätenliste (nach webseiter.de und meinen Kunden).

    Wenn ich mit der gewerblichen mal endlich weiterkomme wird allerdings der eine oder andere Post von hier rüberwandern und eines fernen Tages werde ich dann wohl auch mal den privaten Hobbykram auf Drupal umziehen.

    Letzten Endes verspüre ich da aber keinen Leidensdruck, denn WordPress gets the job done – und das ganz gut, wie ich finde. Mich stört derzeit in erster Linie, dass WordPress so extrem bescheiden performt und da auch nicht mal eben was dran zu drehen ist, ohne sich weitere Probleme einzuhandeln.

  5. Nette Idee, aber was passiert mit den dynamisch generierten Teilen der Website? Ich habe z.B. rechts oben den Bereich „beliebte Beiträge“ der aus den Zugriffstats dynamisch generiert wird. Wäre ja blöde den nur immer dann aktualsiiert zu sehen, wenn ein neuer Kommentar oder Post hinzu gekommen ist. Je nachdem wie der Blog läuft kann da einiges an Zeit zwischen liegen.

Kommentare sind geschlossen.