WordPress ist ein sehr universelles Blogging- und mittlerweile auch CMS-System. Um die universelle Einsetzbarkeit zu erhalten, ist WP nahezu durchgehend so programmiert, daß selbst kleinste Stylesheet-Informationen usw. durch Datenbankabfragen erledigt werden. Vor allem in den Vereinigten Staaten wird heftig diskutiert, ob man bei der Anpassung vorhandener Templatedateien nun besser hardcoden sollte oder nicht. Die einen sagen, es bringe ungeheure Vorteile, die anderen sagen es brächte nur einen minimalen Geschwindigkeitszuwachs. Hier erkläre ich, was gemeint ist:
Wenn man sich für ein gewisses Theme bzw. Template entschieden hat, kennt dieses ja automatisch z.B. den Blognamen und die Pfade zu den Templatedateien. Diese Informationen bezieht das Theme aus solchen Datenbankabfragen:
Hier wird z.B. für die Angabe des Pfades zur CSS-Datei style.css die Datenbank bemüht und zwar genau in diesem Teil hier:
Es ist klar, der Autor des Themes kann ja nicht wissen, welches Verzeichnis und welche Angaben für Dein spezielles Weblog zutreffen. Deshalb fragt er in seinen Theme-Dateien all diese Informationen aus der Datenbank ab. Und das Theme ist voll von solchen Anfragen, es können Hunderte sein. Manche behaupten nun, daß diese Anfragen an die Datenbank, trotz aller Caching-Mechanismen, einen gewissen Verzögerungseffekt mitbringen. Das scheint auch zunächst einmal logisch, denn jede Abfrage an die Datenbank verbraucht Zeit und seien es nur Millisekunden, das kann sich ganz schön addieren.
Es wäre aber nun albern, wollte man alle diese Datenbankaufrufe eliminieren, denn dadurch ginge u.U. die gesamte Dynamik eines WP-Weblogs verloren. Außerdem sind die Datenbankabfragen quer über alle Dateien eines Themes verteilt und diese Dateien werden ja nun nicht immer alle aufgerufen, sondern es sind zumeist die Dateien header.php, eine bestimmte Seite, z.B. die Indexseite, die Archivseite oder die Einzelartikelansicht und die footer.php.
Die header.php ist dafür zuständig, den HTML-Header für die ausgegebenen HTML-Seiten zu erzeugen und diese Datei wird deshalb naturgemäß immer und damit sehr häufig aufgerufen. Gerade in dieser Datei sind aber schon vom Start weg extrem viele Datenbankabrufe enthalten, die quasi als Platzhalter fungieren und erst durch die Datenbank mit Inhalten gefüllt werden. Das kostet u.U. Zeit und Performance.
Da die header-Datei zum jeweiligen Template gehört, kann man sie also ohne weiteres ändern und diese Datenbankabfragen durch hardcodierte Pfadangaben ersetzen.
(Ich spreche immer wieder auch von Template, wenn ich das Theme meine, das ist der Tatsache geschuldet, daß ich auch viel mit der Weblogsoftware serendipity arbeite, wo das eben anders heißt.)
Mittels eines FTP-Programms zieht man sich zuerst einmal ein Backup seiner Templatedateien und benennt die header.php in oldheader.php um.
Danach öffnen wir diese Datei in einem Editor und im Browser lassen wir uns den Seitenquelltext (Menü Ansicht o.ä. des Browsers) anzeigen.
Nun haben wir beide Versionen vor uns:
1. die Ansicht der header.php mit den ganzen Platzhaltern
2. die bereits durch die Datenbank ausgefüllte fertige Version in der Seitenquelltext-Anzeige
Durch einen einfachen Hin- und Her-Vergleich sieht man schon auf den ersten Blick, wo da überall in der Header-Datei Datenbankabfragen stehen und wo WordPress fertigen Code eingesetzt hat.
Geht man nun hin und eliminiert diese ganzen Datenbankabfrage-Platzhalter und ersetzt sie durch fest eingeschriebene (Pfad)angaben, so kann das einen erheblichen Geschwindigkeitsvorteil mit sich bringen.
Schauen wir uns einmal beispielhaft einen Teil des Codes in einer header.php an:
>
<?php bloginfo('name'); ?><?php wp_title(); ?>
Zeilenumbrüche mit ZZZ gekennzeichnet, sonst schießt's mir hier in die Seitenleiste
Überall da, wo hier mit ein Platzhalter gesetzt wird, können wir tätig werden. Bis auf die Zeile mit der Version der Blogsoftware (denn WP wird ja oft mit neuen Versionen beglückt und das ändert sich ja ständig) ist nun etwas Fleißarbeit und Sorgfalt angesagt.
Hier einmal, die Version, die bei mir nach dem Editieren in der header.php steht:
<?php bloginfo('name'); ?><?php wp_title(); ?>
Überall dort, wo ich hier im Beispiel PFAD geschrieben habe, muß man seinen kompletten Pfad zum Theme eintragen, also z.B.:
//dreibeinblog.de/wordpress/wp-content/themes/themename
Auch bei der Angabe für den Feed und die Pingbacks habe ich die Datenbankabfragen durch hardcodierte Pfadangaben ersetzt.
Danach speichert man die Datei unter header.php ab und lädt sie in sein Themeverzeichnis hoch. Falls etwas schiefgegangen ist, handelt es sich meist um Tippfehler, die man durch sorgfältiges Vergleichen leicht beseitigen kann. Im Falle eines Falles löscht man die header.php wieder vom Server und spielt die vorher angelegte oldheader.php als neue/alte header.php wieder hoch. Dann hat man zwar nix gewonnen, es läuft aber auch alles wieder.
Hier noch einmal eine Liste der Codes, die man leicht editieren kann:
< ?php language_attributes(); ? >
< ?php bloginfo(’html_type’); ? >
< ?php bloginfo(’charset’); ? >
< ?php bloginfo(’template_url’); ? >
< ?php bloginfo(’pingback_url’); ? >
< ?php bloginfo(’name’); ? >
< ?php bloginfo(’url’); ? >
Wiegesagt: Die header.php zeigt, wo die Platzhalter sind und die Seitenquelltextanzeige zeigt, was WP statt der Platzhalter einträgt. Diese eingetragenen Sachen setzt man nun dort ein, wo vorher die Platzhalter waren:
< ?php language_attributes(); ? > xhtml" dir="ltr" lang="de-DE"
< ?php bloginfo(’html_type’); ? > text/html
< ?php bloginfo(’charset’); ? > utf-8
< ?php bloginfo(’template_url’); ? > http://DEINPFADZUMTHEME
< ?php bloginfo(’pingback_url’); ? > http://DEINEURL/xmlrpc.php
< ?php bloginfo(’name’); ? > DEINBLOGNAME
< ?php bloginfo(’url’); ? > http://DEINEURL
Je nach Theme kann das eine Menge Arbeit sein und es ist und bleibt fraglich, ob der Geschwindigkeitsvorteil wirklich bedeutend ist. Die einen sagen so, die anderen sagen so...
Ich habe noch einmal die wichtigsten Schlagwörter (Hashtags) dieses Artikels für Sie zusammengestellt, damit Sie sich besser orientieren können:
