Ich wundere mich schon seit einer Weile über eigenartige Crawling-Fehler, die mir in den Webmaster Tools unter Diagnose angezeigt werden. Sie sehen beispielsweise so aus:

http://www.xsized.de/wp-login.php?action=logout&redirect_to=http%3A%2F%2Fwww.xsized.de%2Fein-ende%2F&_wpnonce=xxxxxxxxxx

Alle erzeugten einen 403-Fehler und verschlechtern natürlich die Bewertung des eigenen Blogs bei Google. Seiten mit fehlerhaften Links sind unschön und somit auch nicht wichtig. Also mal im Seitenquelltext nachgeschaut und festgestellt: Der Link wie oben im Beispiel dargestellt wird durch die WordPress Admin-Bar in die Seite eingefügt. OK, gut und schön, nachvollziehbar. Nur warum zur Hölle sieht der Crawler von Google die Admin-Bar?

Des Rätsels Lösung scheint in meinem Fall das Plugin W3 Total Cache zu sein. Dieses Plugin beschleunigt die Auslieferung der Inhalte, indem es diverse Caching-Mechanismen aktiviert. Unter anderem cached es auch die fertig zusammengebauten Seiten für eine gewisse Zeit auf der Festplatte und kann im Idealfall diesen Cache ausliefern, statt erst den deutliche längeren Weg über Datenbankabfragen nehmen zu müssen. Dieses Feature hatte mir schon einmal den Allerwertesten gerettet, als aufgrund eines massiv retweeteten Blogeintrages urplötzlich hunderte von Besuchern binnen 2-3 Minuten hier aufschlugen…

Nun, soweit, so schön. Aber eigentlich hatte ich erwartet, dass aufgrund der Aktivierung von „Don’t cache pages for logged in users“ im Plugin meine Besuche NICHT gecached werden würden. Macht ja auch Sinn, anderenfalls würden Besucher meiner Seite unter Umständen MEINE Admin-Bar im Quelltext ausgeliefert bekommen. Und möglicherweise auch angezeigt… Überhaupt nicht schön. Nur scheint es exakt an diesem Punkt einen Bug im Plugin W3 Total Cache zu geben, denn ganz offensichtlich wurde meine Besuche sehr wohl gecached, nur nicht aus dem Cache an mich ausgeliefert. Googles Crawler hingegen hat die Seiten offenbar aus dem Cache bekommen, MIT meiner Admin-Bar. Und lief beim überprüfen der Links dann in den „403 Forbidden“-Fehler. Unschön.

Da ich die Admin-Bar ohnehin nicht nutze, habe ich sie nun kurzerhand ausgeblendet. Eine sehr einfache Möglichkeit dazu habe ich im Blog von WordPress Deutschland gefunden und somit war es nur eine Sache von einer Minute. Es gibt nun keine Admin-Links mehr in der Seite, auch nicht, wenn ich eingeloggt bin. Somit kann auch nichts falsches gecached und ausgeliefert werden. Problem (offenbar) gelöst. Werde in den nächsten Tagen mal verstärkt darauf achten, wie es in den Webmaster Tools aussieht.

WordPress ist gelegentlich nicht wirklich sehr schnell bei der Auslieferung von Seiten. Das hängt unter anderem auch mit der Vielzahl von Datenbankabfragen zusammen, die WordPress pro Aufruf durchführt. Zu einem Problem kann das werden, wenn viele User gleichzeitig ein WordPress-Blog aufrufen und Speicher sowie Prozessorkapazität auf dem Host arg begrenzt sind. Verschärft wird das Problem durch Plugins und Widgets, die gelegentlich auch noch gern Scripte von anderen Seiten nachladen und somit die Ladezeit noch zusätzlich verlängern. Vom Speicherverbrauch dieser Extras mal gar nicht zu reden…

Optimierungsmöglichkeiten gibt es hier einige, überflüssige Gimmicks und Plugins zu entfernen wäre eine Möglichkeit, die man als erstes in Angriff nehmen sollte, wenn die Ladezeit des Blogs zu lang wird. Aber auch Caching trägt einen guten Teil zur Beschleunigung einer Seite bei.

Ich habe hier auf meinem Blog seit 3-4 Wochen das Caching-Plugin W3 Total Cache im Einsatz. Der Geschwindigkeitszuwachs beim laden der Seite war deutlich spürbar. Die Ladezeiten meines Blogs lagen laut Webmaster Tools vor dem Einsatz des Plugins bei teilweise bis zu 8-10 Sekunden, vor allem bei Einträgen mit vielen Kommentaren. Hier hatte ich zunächst die Paged Comments aktiviert (sieht man ja bereits seit einiger Zeit) und so ca. 1 Sekunde Ladezeit gewonnen. Mit dem Plugin ging die Ladezeit der langsamsten Seiten dann herunter auf unter 4, teilweise unter 3 Sekunden. Ziemlich flott, wie ich finde. Weitere Optimierungsmöglichkeiten würde ich jetzt noch am Template sehen, hier kommt aber möglicherweise demnächst ohnehin etwas ganz anderes.

Vor 2 oder 3 Tagen hatte ich ein weiteres Caching-Plugin für WordPress getestet: Hyper Cache. Und ich fand, dass die Seite noch einmal spürbar flotter geladen wurde. Zumindest in Chrome, den ich ja einsetze. Subjektiv war die Seite richtig schnell, messbar war es noch nicht, da die Webmaster Tools ja immer mit ein paar Tagen Verzögerung die Wirkung einer Maßnahme anzeigen.

Leider wurde mir allerdings gestern gemeldet, dass mein Blog „völlig zerschossen“ sei. Der erste Check mit Chrome brachte nix, sah alles toll aus, keine Probleme zu sehen. Doch dann versuchte ich es mit dem Firefox und meine Seite sah so aus (was möglicherweise einigen von Euch ebenfalls aufgefallen ist):

Schick, oder?

Nach einer ersten Schrecksekunde fiel mir auf: Moment, exakt so sehen die Cache-Files aus, die Hyper Cache auf der Platte ablegt. Also Hyper Cache deaktiviert, erneut geprüft und alles war wieder schick.

Bisher habe ich noch keine Lösung gefunden, ich hab noch keinen Schimmer, warum Firefox die Seiten nicht darstellen kann, wenn Hyper Cache aktiviert ist. Ich hoffe, hier noch eine Lösung finden zu können denn ich empfand die Beschleunigung durch Hyper Cache doch noch etwas besser als die, die mir W3 Total Cache liefert. Die ist durchaus auch nicht schlecht, keine Frage, aber Hyper Cache war eben subjektiv einen Touch flotter. Was nur leider nichts bringt, wenn die Browser die Seiten anschließend nicht mehr darstellen können.