Alex King ist einem interessanten WordPress-Phänomen auf den Grund gegangen: Eine Website war nach der Übersiedlung auf einen anderen Server plötzlich entschieden langsamer, und das trotz intensiver Tests vor der Übersiedlung. Verursacht wurde der Geschwindigkeitseinbruch durch Grafikdateien, die auf der neuen Website nicht mehr vorhanden waren.

Wie kann eine nicht vorhandene Datei eine Website massiv verlangsamen? Die Erklärung liegt zwar nicht auf der Hand, ist aber verständlich, wenn man über die Wege nachdenkt, die eine Anforderung an den Server im System nimmt.

Prinzipiell unterscheiden Websites, die mit WordPress betrieben werden, zwischen zwei Arten von Ressourcen:

  1. Als Dateien vorliegende Ressourcen werden von Webserver (Apache, IIS, lighttp) direkt an den Browser gesandt – WordPress bekommt davon nichts mit.
  2. Wird eine Ressource angefordert, die nicht als Datei vorliegt, beginnt WordPress mit der Arbeit. Dieses Verhalten ist bei Einsatz von Apache über eine Rewrite-Regel in .htaccess implementiert:
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /wordpress/index.php [L]

In einfachen Worten: Ist die Anfrage des Besuchers weder durch eine Datei noch durch ein Verzeichnis beantwortbar, verarbeite /wordpress/index.php.

Damit ist auch klar, was bei nicht vorhandenen Galeriebildern, fehlenden Scripts oder Stylesheets passiert: WordPress startet, verbindet sich mit der Datenbank, sucht in den Optionen nach einer passenden Permalink-Struktur, versucht dann einen zur Anforderung passenden Beitrag, eine Kategorie, einen Tag oder eine Seite zu finden – und scheitert viele Millisekunden später.

Natürlich bleibt das Fehlen von Bildern oder Scripts nicht lange unbemerkt. Weniger auffällig ist das Fehlen von Dateien, ohne die dein Blog uneingeschränkt funktioniert. Ein paar Kandidaten dafür sind:

  • /robots.txt wird von jedem “höflichen” Suchmaschinenspider gesucht.
  • /favicon.ico laden ältere Browser bei jedem Zugriff.
  • Hintergrundbilder, die über background-image: url(/was/auch/immer.jpg) in Stylesheets geladen werden sollten – wer schon mal ein wenig am Design seines Themes herumgespielt hat, weiss, dass hier gerne ein paar Leichen im Keller vergessen werden. Selbst Theme-Autoren vergessen schon mal die eine oder andere veraltete Zeile beim Update eines Stylesheets.

Und das Schlimme daran: Als Websitenbetreiber merkst du vorderhand nichts davon außer der Klage, dass dein Blog unter Volllast langsam reagiert. In den Logdateien von Apache tauchen Requests für fehlenden Ressourcen je nach Konfiguration gar nicht auf, weil der Webserver die Auslieferung an WordPress delegiert und damit von der folgenden Verarbeitung nichts mehr mitbekommt. WordPress selbst führt auch keine Aufzeichnungen über fehlgeschlagene Requests.

Am einfachsten kommt man solchen Anfragen mit dem Plugin Redirection auf die Spur.

Aus dem von Redirection geführten Logbuch über nicht gefunden Ressourcen lassen sich auch gleich Umleitungen zu Ersatz-URLs definieren, wenn’s nötig erscheint. Klar muss einem aber auch sein, dass die Aufzeichnungen schnell recht umfangreich werden – es gibt einfach zu viele Script-Kiddies und schlecht programmierte Spider, die Zugriffe auf den absonderlichsten Adressen versuchen. Am besten ist, die Aufzeichnungen für einige Zeit laufen zu lassen, eventuell gefundene Fehler zu beheben und das Logging anschließend über die Redirection-Optionen wieder auszuschalten.

31. Juli 2008, 22:17 − Abgelegt in

Kommentare

Alternativ kann man das auch in einem Test mit Firefox und dessen Add ons Firebug und YSlow sehr gut analysieren.
Will man es automatisch machen, so kann ich aus meinem Werkeln das Plugin 404 Notifier empfehlen. Damit erhält die Meldungen als Feed.

Frank · 1. August 2008, 11:33 · #

Kommentarfunktion für diesen Artikel geschlossen.