bertdesign.de

WordPress-Installationen wer­den schnell „träge” – viele Datenbank-Abfragen & nach­läs­si­ges Coding in The­mes füh­ren zu lang­sa­mem Sei­ten­auf­bau. Die­ses Pro­blem kann man auf viel­fäl­tige Art lösen. Die­ser Bei­trag fasst einige Vor­schläge zusam­men. Dabei geht es einer­seits darum, mit direk­ten Code-Veränderungen im jewei­li­gen Theme Datenbank-Abfragen zu mini­mie­ren & den Code zu opti­mie­ren. Ande­rer­seits wird auch kurz auf einige sinn­volle Plugins eingegangen.

Gene­rel­les

Grund­sätz­lich sollte man natür­lich einige Punkte beach­ten, die keine Code-Veränderungen oder ande­res benötigen:

• Stets die aktu­ellste Word­Press–Ver­sion nutzen
• Unnö­tige / unge­nutzte Plugins deak­ti­vie­ren oder bes­ser noch löschen
• Valide, gut gecodete The­mes nutzen

Dar­über hin­aus kann man aber noch wei­tere Maß­nah­men ergreifen:

Datenbank-Abfragen mini­mie­ren

Etli­che Datenbank-Abfragen in ver­schie­de­nen The­mes wer­den (selbst­ver­ständ­lich) durch PHP varia­bel gehal­ten. So ist garan­tiert, dass der ent­spre­chende Code mit dem jeweils rich­ti­gen Pfad aus­ge­stat­tet wird. Häu­fig genutzte Template-Tags sind:

bloginfo('name');
bloginfo('charset');
bloginfo('stylesheet_url');
bloginfo('rss2_url');

Den Groß­teil der Varia­blen fin­det man zumeist in der Datei header.php. Nun ist es ein Leich­tes, diese Varia­blen nach der erfolg­rei­chen Instal­la­tion des jewei­li­gen The­mes durch sta­ti­schen HTML-Code zu erset­zen. Dazu lässt man sich den Quell­text (z.B.) der Start­seite des Blogs anzei­gen. Dort wur­den die Varia­blen natür­lich bereits in sta­ti­schen HTML-Code umge­formt, so dass die­ser ein­fach aus dem Quell­text kopiert & im Theme ersetzt wer­den kön­nen. Laut Joost de Valk kön­nen dadurch bis zu elf Daten­bank­an­fra­gen ent­fernt wer­den – ziem­lich viel, oder? Nein, wie Frank Bültge in den Kom­men­ta­ren anmerkt – die Daten wer­den gecacht, somit kann man sich das Rum­spie­len im Theme sparen.

Übri­gens: Die Anzahl der Datenbank-Abfragen kann man sich direkt von Word­Press anzei­gen las­sen. Sinn­voll ist, diese Daten nur für Admi­nis­tra­to­ren anzei­gen zu las­sen. Fol­gen­der Code – etwa im Fuß­be­reich 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 ein­fa­chen PHP-Befehl kann man bei der Gene­rie­rung des The­mes schon mal den Head-Bereich der Seite raus­schi­cken, so dass sich der Brow­ser schon mal um die dort ver­link­ten Dateien „küm­mern” kann:

</head>
<?php flush(); ?>

Ob der Effekt in der header.php einen signi­fi­kan­ten Effekt hat oder bes­ser in der index.php (o.Ä.) direkt hin­ter dem Auf­ruf der header.php plat­ziert wer­den sollte, kann ich lei­der nicht beur­tei­len – happy tes­ting Sinn­voll erscheint die Maß­nahme aber gene­rell schon.

All­ge­meine Code-Optimierung

Die Yahoo Performance-Guidelines fas­sen einige Maß­nah­men zur Performance-Optimierung zusammen:

• HTTP-Requests mini­mie­ren
• Style­s­heets im Kopf­be­reich der Seite
• Javascript-Dateien im Fuß­be­reich der Seite
• Alle Skripte & CSS-Dateien als externe Dateien einbinden
• Skripte & Dateien zusammenfassen

Die prak­ti­sche Fire­Bug–Erwei­te­rung YSlow schaut sich die in den Gui­de­lines ange­spro­che­nen Punkte an & bewer­tet die Sei­ten­per­for­mance. Zur Ana­lyse in Fire­Fox somit ein sehr gut geeig­ne­tes Tool, um poten­ti­elle Performance-Bremsen aus­zu­ma­chen & zu entfernen.

Oft pas­siert es zudem, dass Plugins zusätz­li­chen Code in den Kopf– oder Fuß­be­reich der Seite ein­fü­gen. Das kann man über ein paar Zei­len Code in der functions.php unter­bin­den. Wie das funk­tio­niert, erklärt Jus­tin Tad­lock. Für diese Maß­nahme ist eini­ges an Hand­ar­beit inklu­sive Code-Analyse der Plugins nötig – der Auf­wand lohnt aber, wenn statt meh­re­ren Style­s­heets etwa nur ein ein­zi­ges gela­den wer­den muss.

Caching-Plugins

Einige der oben beschrie­be­nen Auf­ga­ben kön­nen auch Caching-Plugins über­neh­men. Recht bekannt & beliebt ist hier das Plu­gin WP Super Cache, das aus den auf­ge­ru­fe­nen Sei­ten regel­mä­ßig sta­ti­sche HTML-Seiten erstellt, so dass sämt­li­cher Datenbank-Stress ent­schärft wird. Die­ses Plu­gin wird z.B. von Spree­blick eingesetzt.

Seit kur­zem teste ich hier W3 Total Cache, das über die Mög­lich­kei­ten von WP Super Cache noch ein gan­zes Stück hin­aus geht – die recht beein­dru­ckende Liste der Nut­zer hat mich neu­gie­rig gemacht. Über die­ses Plu­gin las­sen sich viel­fäl­tige Opti­mie­rungs­ein­stel­lun­gen vor­neh­men, die stark von den oben ange­spro­che­nen Yahoo Performance-Guidelines beein­flusst sind. Dabei kann man etwa eine eigene Sub­do­main anle­gen & als CDN nut­zen. Nach einer inten­si­ven Dis­kus­sion zur Frage ob das lohnt, stellte Chris Coy­ier fest:

I think the gene­ral con­sen­sus is that YES, it is a good idea. If you can map the sub­do­main to a dif­fer­net ser­ver ent­i­rely, one run­ning a strip­ped down web ser­ver with spe­cial set­tings and stuff (aggres­sive caching, cookie-less) OR you can map it to a bona­fied CDN, that’s cle­arly better.

Howe­ver, just the sub­do­main all by its­elf seems like it has bene­fits enough that it is worth doing.

Die wei­te­ren Ein­stel­lun­gen sind sehr sehr umfang­reich & meist auch sehr sinn­voll, wes­halb ich das Plu­gin wärms­tens emp­feh­len kann.

Nach­trag: Jens ver­weist in den Kom­men­ta­ren auf DB-Cachebes­ser, weil für WP 2.8 geschrie­ben: DB Cache reloa­ded, das zumin­dest im Ver­gleich zu WP Super Cache schein­bar etli­che Vor­teile besitzt:

I think you’ve heard of WP-Cache or WP Super Cache, they are both top plugins for Word­Press, which make your site fas­ter and responsive. For­get about them — with DB Cache your site will work much fas­ter and will use less disk space for cached files. Your visi­tors will always get actual infor­ma­tion in side­bars and ser­ver CPU loads will be as low as posible.

Das werde ich mal tes­ten & die von W3 Total Cache über­nom­me­nen Auf­ga­ben weit­ge­hend per Hand regeln – bei der Kom­pri­mie­rung der JavaScript-Dateien stellt sich das Plu­gin etwas sper­rig an…

Fazit

Nach­trag (29.01.2010): Nach eini­gen Tests lau­fen hier (und auf diver­sen ande­ren „mei­ner” WP-Installationen) sowohl DB Cache reloa­ded als auch WP-SuperCache. Die bei­den Plugins ergän­zen sich dabei ganz gut – wäh­rend DB Cache reloa­ded wenn nötig die ein­zel­nen Daten­bank­ab­fra­gen spei­chert,  legt WP-SuperCache direkt die kom­plet­ten Sei­ten auf dem Ser­ver als HTML-Image ab. Das geht natür­lich ent­spre­chend schnel­ler, wenn einige Standard-Datenbank-Abfragen (wie etwa in der Sei­ten­leiste) bereits gespei­chert wur­den und bei der nächs­ten auf­ge­ru­fe­nen Seite nicht mehr die Daten­bank / den Ser­ver belas­ten. Gutes Zusam­men­spiel also, das bei mir noch kei­ner­lei Pro­bleme erzeugt hat.

Ich hoffe, dass ich einen halb­wegs voll­stän­di­gen & sinn­vol­len Über­blick zur Opti­mie­rung von WordPress-Installationen geben konnte. Sollte ich etwas ver­ges­sen haben, in einem Punkt völ­lig dane­ben lie­gen oder alles super beschrie­ben haben, freue ich mich über jed­we­des Feed­back in den Kom­men­ta­ren & Herzchen-Klicks

Und jetzt: Viel Spaß beim Optimieren!

Ähnliche Artikel

• Wordpress Dashboard aufdonnern
• Wie man CSS3 und HTML5 schon nutzen kann
• Zensursula deluxe!?