Blogoptimierung – woher kommt der Speed – Teil 2

18. Dezember 2009 | Von Kim Hübel | Kategorie: Web 2.0

Nachdem wir  uns im 1. Teil dieser Reihe mit dem Thema “Auftrennung in statischen und dynamischen Content” beschäftigt haben, möchten wir heute dem dynamisch erzeugten Content speziell bei WordPress-Blogs ein wenig auf den Leib rücken.

Optimierung der dynamischen WordPress-Codes

Um im Bereich der dynamischen Generierung des WordPress-Blogs Optimierungen vornehmen zu können, sollte man sich zunächst einmal klar darüber werden, wo man hier genau ansetzen kann. Genauer gesagt: Wo liegen die Schwachpunkte, wo geht Zeit verloren beim Seitenaufbau, was kann man dagegen tun?

Ein Grundproblem haben alle dynamischen Seiten gemeinsam: Ihre Inhalte kommen in aller Regel aus einer Datenbank heraus. Welche Optimierungsmöglichkeiten man bezogen auf die Datenbank besitzt, dazu werde ich in einem weiteren Teil dieser Reihe zu sprechen kommen. Generell sollte man sich jedoch eine zentrale Frage stellen: Wie kann ich Datenbankzugriffe vermeiden?

Festlegung von Variablen-Konstanten

WordPress hat die unfeine Eigenart, verschiedene Dinge bei jedem Laden der Seite von der Datenbank erfahren zu wollen. Dazu gehören z.B. rudimentäre Dinge wie z.B. die WordPress-Adresse und die Blog-Adresse (beides übrigens Punkte, die der Benutzer unter den Einstellungen im Punkt “Allgemein” einträgt). Da sich diese Dinge jedoch über die Laufzeit eines Blogs höchst selten ändern, wäre es doch sinnreich, diese dem dynamischen PHP-Code auf einem etwas statischeren Wege mitzuteilen. Und genau dafür bietet WordPress die Möglichkeit beispielsweise über die Datei wp-config.php Konstanten zu definieren. Hier für dieses Blog wurde z.B. folgende Eintragung vorgenommen:

define(‘WP_HOME’, ‘http://www.technikel.de’);
define(‘WP_SITEURL’, ‘http://www.technikel.de’);

Damit weiß das Blog bereits vor der ersten Verbindung zur Datenbank Bescheid, welche Werte diese beiden Variablen haben und braucht sie nicht mehr in der Datenbank nachschlagen. Ähnliches lässt sich mit den Variablen TEMPLATEPATH und STYLESHEETPATH auch tun, jedoch sollte man hier etwas vorsichtiger sein, da man sich hier schnell den Wechsel des Themes erschwert, weil man sich nicht mehr unbedingt an die Festlegung dieser Variablen erinnert.

Vermeidung von Funktionsaufrufen

Das verwendete WordPress-Theme bietet sehr viele Ansatzpunkte um Optimierungen bezogen auf die Arbeitsgeschwindigkeit vorzunehmen. Wer sich seine Theme-Dateien (speziell die PHP-Dateien sind hier gemeint) genauer anschaut, findet dort immer wieder Funktionsaufrufe, die irgedendwelche Daten zurückliefern, die man im Grunde jedoch kennt und die sich eigentlich auch nicht verändern (wie z.B. die oben genannten Variablen). Warum also nicht einfach im Theme entsprechend diese Passagen durch den konkreten Text ersetzen? Dies erspart ggf. wieder weitere Datenbankzugriffe – zumindest wird es jedoch ein Funktionsaufruf weniger, der irgendwelches Wissen aus dem Speicher kramen muss.

Plugins – notwendig oder unnötiger Ballast?

Massiv für die Ladezeit verantwortlich ist neben dem verwendeten Theme und seinen Funktionsaufrufen die Anzahl bzw. auch die Art der verwendeten Plugins. Mögen einige Plugins zwingend erforderlich sein für  einen sicheren oder angenehmen Betrieb des Blogs (z.B. Anti-Spam-Plugins, die Kommentarspam minimieren), so sind andere Plugins vielleicht schlichtweg Luxus und wären durch ein wenig Hirnschmalz und ein bisschen eigenem PHP-Code in der Funktion genauso gut implementiert – mit dem Vorteil, dass das  Blog selbst schneller arbeitet! Hier sollte man sich die Liste der von einem selbst verwendeten Plugins von Zeit zu Zeit mal durchgehen unter dem Gesichtspunkt: Brauche ich die Funktion, die das Plugin bietet wirklich?

Häufig ist es nämlich so, dass man aufgrund eines kurzfristigen Hypes irgendwelche Gimmiks in seinem Blog umsetzen möchte, die schlussendlich die Leser nicht interessieren. Ein Plugin, was keinen Mehrwert bietet, ist somit ein unnötiges Plugin. Da kann es noch so schön daher kommen. Die einzig richtige Konsequenz in diesem Fall: Deaktivieren und Löschen.

Ähnlich verhält es sich mit den Punkten in der Sidebar. Diese gehört auch hin und wieder einer Revision unterzogen. Häufig verstecken sich nämlich hinter unscheinbaren Widgets einer dynamischen Sidebar richtige Performance-Bremsen. Die Anzahl der Datenbankabfragen und somit auch die Ladezeit wird sich spontan verringern, was sich positiv auf die Psyche des Lesers und des Bloggers gleichzeitig auswirkt.

Sowieso ist das Thema Sidebar und die Gestaltung derselben ein Punkt, der vielleicht einen eigenen Artikel wert wäre. In diesem Zusammenhang möchte ich nur dazu raten, die Sidebars nicht mit jedem Müll voll zu laden.

Wie man sieht, ist auch dieser Punkt der Optimierung kein Hexenwerk und mit ein wenig Vorsicht von jedem durchaus durchführbar.

Lesetipps im WWW


Ähnliche Artikel

  1. Blogoptimierung – woher kommt der Speed – Teil 1
  2. Blogoptimierung – woher kommt der Speed – Teil 3
  3. WordPress 2.9 veröffentlicht
  4. Wie wehrt man sich im Blog gegen Spam?
Tags: , , , , , , ,

3 Kommentare
Hinterlasse einen Kommentar »

  1. Hallo Kim,

    ein altbekannter mit neuem Gesicht :-)
    Vielen Dank für die freundliche Empfehlung und Dir viel Erfolg mit dem Startup! :-)

    antwortenReply to this comment
  2. @Plerzelwupp:
    Bitte, gerne geschehen :-) Dieses Blog ist aber (vorerst – ich denke das wird auch nicht großartig anders werden) auch nur ein “hobbymäßig” betriebenes Blog, allerdings mit ganz klarer thematischer Ausrichtung, wie man an den noch sehr leeren Kategorien erkennen kann. Aber ich arbeite ja bereits ein wenig daran, hier leben reinzubekommen… wenn dann die ersten Beiträge mal so in den Kategorien drin sind, dann denke ich, werde ich auch mal “rundziehen” und ein wenig offensiver das ganze “ins Gespräch” bringen… wobei ich dabei ja auch nie aufdringlich werden will.

    Weißt ja, wie ich das meine und du hast ja selbst Erfahrung genug, dass du weißt, wie vorsichtig man vorgehen muss, um nicht gleich als SEO-Spammer oder dergleichen eingestuft zu werden.

    antwortenReply to this comment
  3. Gerade bei dem Sidebar Argument muss ich Dir Recht geben. Die meisten Datenbankabfragen produziert z.B. das Plugin Popular Posts. Da ich auf dieses Plugin aber trotzdem nicht verzichten mag, habe ich seine Ausgaben, die ich in Sidebar und Footer produziere in meinen manuellen PHP Cache gesetzt und lasse sie 1x täglich oder so aktualisieren. Ebenso das Similar Posts Plugin in den Artikeln selbst (hier aktualisiere ich z.B. nur 1x pro Woche). Für jeden einzelnen Seitenaufruf sind das ziemlich unnötige Datenbankabfragen (bei 5 Ausgabelinks z.B. nicht selten 20 Abfragen), denn so häufig ändert sich hier nichts.

    antwortenReply to this comment

Schreibe einen Kommentar

Additional comments powered by BackType