WordPress: Performance optimieren
WordPress-Installationen werden schnell „träge” – viele Datenbank-Abfragen & nachlässiges Coding in Themes führen zu langsamem Seitenaufbau. Dieses Problem kann man auf vielfältige Art lösen. Dieser Beitrag fasst einige Vorschläge zusammen. Dabei geht es einerseits darum, mit direkten Code-Veränderungen im jeweiligen Theme Datenbank-Abfragen zu minimieren & den Code zu optimieren. Andererseits wird auch kurz auf einige sinnvolle Plugins eingegangen.
Generelles
Grundsätzlich sollte man natürlich einige Punkte beachten, die keine Code-Veränderungen oder anderes benötigen:
- Stets die aktuellste WordPress–Version nutzen
- Unnötige / ungenutzte Plugins deaktivieren oder besser noch löschen
- Valide, gut gecodete Themes nutzen
Darüber hinaus kann man aber noch weitere Maßnahmen ergreifen:
Datenbank-Abfragen minimieren
Etliche Datenbank-Abfragen in verschiedenen Themes werden (selbstverständlich) durch PHP variabel gehalten. So ist garantiert, dass der entsprechende Code mit dem jeweils richtigen Pfad ausgestattet wird. Häufig genutzte Template-Tags sind:
bloginfo('name');
bloginfo('charset');
bloginfo('stylesheet_url');
bloginfo('rss2_url');
Den Großteil der Variablen findet man zumeist in der Datei header.php. Nun ist es ein Leichtes, diese Variablen nach der erfolgreichen Installation des jeweiligen Themes durch statischen HTML-Code zu ersetzen. Dazu lässt man sich den Quelltext (z.B.) der Startseite des Blogs anzeigen. Dort wurden die Variablen natürlich bereits in statischen HTML-Code umgeformt, so dass dieser einfach aus dem Quelltext kopiert & im Theme ersetzt werden können. Laut Joost de Valk können dadurch bis zu elf Datenbankanfragen entfernt werden – ziemlich viel, oder? Nein, wie Frank Bültge in den Kommentaren anmerkt – die Daten werden gecacht, somit kann man sich das Rumspielen im Theme sparen.
Übrigens: Die Anzahl der Datenbank-Abfragen kann man sich direkt von WordPress anzeigen lassen. Sinnvoll ist, diese Daten nur für Administratoren anzeigen zu lassen. Folgender Code – etwa im Fußbereich der Seite – macht das möglich:
<?php if (current_user_can('level_10')) {
echo '<!-- '
. get_num_queries()
. ' Abfragen in '
. timer_stop(0,3)
. ' Sekunden -->';
} ?>
Flush early
Mit einem einfachen PHP-Befehl kann man bei der Generierung des Themes schon mal den Head-Bereich der Seite rausschicken, so dass sich der Browser schon mal um die dort verlinkten Dateien „kümmern” kann:
</head> <?php flush(); ?>
Ob der Effekt in der header.php einen signifikanten Effekt hat oder besser in der index.php (o.Ä.) direkt hinter dem Aufruf der header.php platziert werden sollte, kann ich leider nicht beurteilen – happy testing 
Sinnvoll erscheint die Maßnahme aber generell schon.
Allgemeine Code-Optimierung
Die Yahoo Performance-Guidelines fassen einige Maßnahmen zur Performance-Optimierung zusammen:
- HTTP-Requests minimieren
- Stylesheets im Kopfbereich der Seite
- Javascript-Dateien im Fußbereich der Seite
- Alle Skripte & CSS-Dateien als externe Dateien einbinden
- Skripte & Dateien zusammenfassen
Die praktische FireBug–Erweiterung YSlow schaut sich die in den Guidelines angesprochenen Punkte an & bewertet die Seitenperformance. Zur Analyse in FireFox somit ein sehr gut geeignetes Tool, um potentielle Performance-Bremsen auszumachen & zu entfernen.
Oft passiert es zudem, dass Plugins zusätzlichen Code in den Kopf– oder Fußbereich der Seite einfügen. Das kann man über ein paar Zeilen Code in der functions.php unterbinden. Wie das funktioniert, erklärt Justin Tadlock. Für diese Maßnahme ist einiges an Handarbeit inklusive Code-Analyse der Plugins nötig – der Aufwand lohnt aber, wenn statt mehreren Stylesheets etwa nur ein einziges geladen werden muss.
Caching-Plugins
Einige der oben beschriebenen Aufgaben können auch Caching-Plugins übernehmen. Recht bekannt & beliebt ist hier das Plugin WP Super Cache, das aus den aufgerufenen Seiten regelmäßig statische HTML-Seiten erstellt, so dass sämtlicher Datenbank-Stress entschärft wird. Dieses Plugin wird z.B. von Spreeblick eingesetzt.
Seit kurzem teste ich hier W3 Total Cache, das über die Möglichkeiten von WP Super Cache noch ein ganzes Stück hinaus geht – die recht beeindruckende Liste der Nutzer hat mich neugierig gemacht. Über dieses Plugin lassen sich vielfältige Optimierungseinstellungen vornehmen, die stark von den oben angesprochenen Yahoo Performance-Guidelines beeinflusst sind. Dabei kann man etwa eine eigene Subdomain anlegen & als CDN nutzen. Nach einer intensiven Diskussion zur Frage ob das lohnt, stellte Chris Coyier fest:
I think the general consensus is that YES, it is a good idea. If you can map the subdomain to a differnet server entirely, one running a stripped down web server with special settings and stuff (aggressive caching, cookie-less) OR you can map it to a bonafied CDN, that’s clearly better.
However, just the subdomain all by itself seems like it has benefits enough that it is worth doing.
Die weiteren Einstellungen sind sehr sehr umfangreich & meist auch sehr sinnvoll, weshalb ich das Plugin wärmstens empfehlen kann.
Nachtrag: Jens verweist in den Kommentaren auf DB-Cachebesser, weil für WP 2.8 geschrieben: DB Cache reloaded, das zumindest im Vergleich zu WP Super Cache scheinbar etliche Vorteile besitzt:
I think you’ve heard of WP-Cache or WP Super Cache, they are both top plugins for WordPress, which make your site faster and responsive. Forget about them — with DB Cache your site will work much faster and will use less disk space for cached files. Your visitors will always get actual information in sidebars and server CPU loads will be as low as posible.
Das werde ich mal testen & die von W3 Total Cache übernommenen Aufgaben weitgehend per Hand regeln – bei der Komprimierung der JavaScript-Dateien stellt sich das Plugin etwas sperrig an…
Fazit
Nachtrag (29.01.2010): Nach einigen Tests laufen hier (und auf diversen anderen „meiner” WP-Installationen) sowohl DB Cache reloaded als auch WP-SuperCache. Die beiden Plugins ergänzen sich dabei ganz gut – während DB Cache reloaded wenn nötig die einzelnen Datenbankabfragen speichert, legt WP-SuperCache direkt die kompletten Seiten auf dem Server als HTML-Image ab. Das geht natürlich entsprechend schneller, wenn einige Standard-Datenbank-Abfragen (wie etwa in der Seitenleiste) bereits gespeichert wurden und bei der nächsten aufgerufenen Seite nicht mehr die Datenbank / den Server belasten. Gutes Zusammenspiel also, das bei mir noch keinerlei Probleme erzeugt hat.
Ich hoffe, dass ich einen halbwegs vollständigen & sinnvollen Überblick zur Optimierung von WordPress-Installationen geben konnte. Sollte ich etwas vergessen haben, in einem Punkt völlig daneben liegen oder alles super beschrieben haben, freue ich mich über jedwedes Feedback in den Kommentaren & Herzchen-Klicks
Und jetzt: Viel Spaß beim Optimieren!