Nachdem ich in den letzten beiden Artikeln (N Gedanken zu “WordPress-Themes optimieren” und Mehr zu “WordPress-Themes optimieren”) vor allem den Einbau der wichtigsten Elemente des HTML-Headers beschrieben habe, welche bei einem WordPress-Theme in der Regel (ohne Einsatz eines entsprechenden SEO-Plugins) fehlen, will ich heute die restlichen Elemente des Header besprechen. Sie sind teilweise nicht ganz unwichtig für die Suchmaschinenoptimierung.
Auch die heutigen Codes können wieder in die functions.php oder – noch besser – in ein Custom Plugin eingepflegt werden, welches alle bisher angesprochenen Funktionalitäten enthalten sollte. Ich denke, dass die bisherigen Beispiele auch eine gute Diskussionsgrundlage darstellen. Wer sich also berufen fühlt, Änderungen vorzuschlagen oder Details der vorgeschlagenen Lösungen in Frage zu stellen, kann das gern in den Kommentaren tun. Ich bin an einem Dialog, der die Thematik weiter beleuchtet und vertieft, sehr interessiert.
Man sollte den Header von Einträgen zu befreien, die man nicht unbedingt braucht. Ich hatte das schon in älteren Artikeln erwähnt, bin dort aber nicht so ins Detail gegangen. Wer sich den Header ansieht, den eine WordPress-Installation standardmäßig so “ausspuckt”, der steht vermutlich vor der Frage, ob man die Einträge braucht oder ob man sich nicht einfach dieser Dinge entledigen kann. Schließlich will man sich kein neues Problem schaffen, indem man einen vielleicht wichtigen Eintrag einfach entfernt.
<meta name="generator" content="..."/>
Dieser Eintrag verrät die Version der WordPress-Installation, was vermutlich nur für Cracker interessant ist. Mit
remove_action ('wp_head', 'wp_generator');
wird die Ausgabe unterbunden. Falls kein Blog-Client verwendet wird, der den RSD-Link benötigt, kann der entsprechende Eintrag mit
remove_action ('wp_head', 'rsd_link');
entfernt werden. Den WLWManifest-Link, der – meines Wissen nach – nur vom Windows Live Writer verwendet wird, wird man mit
remove_action ('wp_head', 'wlwmanifest_link');
los. Die zusätzlichen Feed-Links können mit den Anweisungen
remove_action ('wp_head', 'feed_links', 2);
remove_action ('wp_head', 'feed_links_extra', 3);
vermieden werden. Dazu komme ich später noch einmal. Die zusätzlichen Links im Kopfbereich sind Angaben, die Relationen zu anderen Seiten des Blogs anzeigen. Meines Wissens nach werden die Links nur von Opera als einzigem Browser unterstützt. Zudem ist der Nutzen bei den meisten Blogs für mein Empfinden eher zweifelhaft. Mit den Anweisungen
remove_action ('wp_head', 'index_rel_link');
remove_action ('wp_head', 'start_post_rel_link', 10, 0);
remove_action ('wp_head', 'parent_post_rel_link', 10, 0);
if (!remove_action ('wp_head', 'adjacent_posts_rel_link', 10, 0))
remove_action ('wp_head', 'adjacent_posts_rel_link_wp_head', 10, 0);
wird man auch diese Zeilen los. Die letzten beiden Zeilen sind auf eine Umbenennung der WordPress-Action zurückzuführen, die ich nicht sofort bemerkt hatte. Ich habe mich dafür erst an Frank Bültge gewendet, der schon vor einiger Zeit einen Artikel zum Thema verfasst hatte. Allerdings war ihm wohl das Problem, welches mit WordPress 3.0 dann scheinbar aktuell wird, noch nicht bekannt, sodass ich mir die Quellen genauer angesehen habe, um dann schließlich diesen Fakt festzustellen.
Nachdem die Säuberungsaktion durch ist, sollten wir uns noch einmal den Header ansehen. Der Quelltext ist im Template-Verzeichnis in der header.php zu finden. Ein Vergleich der Sourcen mit der Ausgabe im Browser ist jetzt durchaus sinnvoll. Je nach WordPress-Theme ist die Datei header.php mehr oder weniger umfangreich. Im Augenblick will ich mich aber weiterhin nur auf die Angaben bis zum einleitenden <body>-Tag konzentrieren, was in etwa so aussehen kann:
Die ersten Angaben sind natürlich von Blog zu Blog verschieden. Ich benutze hier XHTML 1.1, was vermutlich reine Geschmackssache ist. Auffällig ist wahrscheinlich die Angabe für den IE8 vor dem Title, über den ich schon im letzten Jahr gemeckert habe. Als nächstes fallen eventuell die Sprachangaben auf. Ich halte es für wichtig, die Suchmaschinen dabei zu unterstützen, die Sprache feststellen zu können.
Nach dem Title und noch vor der Anweisung wp_head() wird das CSS eingebunden, um die Styles aus Performance-Gründen noch vor dem JavaScript zu laden. Aber dazu komme ich im nächsten Abschnitt noch. Weiter unten folgen dann die Verweise zum RSS-Feed der Artikel und zum Commentar-Feed und am Ende wird das Favicon eingebunden. Sicher gehört das Icon nicht zu den wichtigsten Angaben. Aber es ist auch nicht ganz unwichtig.
Falls ihr nicht vorhabt, WordPress mehrsprachig zu verwenden, können alle Werte, wo bloginfo() notiert wurde, auch mit festen Pfadangaben ersetzt werden, um noch ein oder zwei Millisekunden zu sparen. Ansonsten ist der Header soweit optimiert, dass man diese Arbeiten ausführen und dann vergessen kann, weil vorläufig an dieser Front nichts mehr zu tun ist. Abgesehen von einer Sache …
Ich hatte es ja eben schon angesprochen, dass ich das CSS vor dem JavaScript laden möchte. Das wird mit einigen Plugins natürlich reichlich witzlos. Um nicht nach jedem Plugin-Update diesem Problem hinterherzuhetzen, könnte man versuchen, hier in irgendeiner Form einzugreifen, was ich natürlich schon ausgiebig (und erfolglos) getestet habe. In jedem Fall würde das nur eine speziell auf das Blog bezogene Optimierung darstellen, die eher unbefriedigend läuft.
Im Augenblick setze ich dafür ein Plugin ein. Autoptimize ist das entsprechende Plugin, welches von Emilio López stammt und auf das ich vor einiger Zeit durch einen Artikel von my GettoWEB.DE aufmerksam gemacht wurde. Autoptimize ist in der Lage die CSS-Files und alle JavaScript-Files zusammenzufassen. Außerdem verschiebt es das JavaScript an das Ende des HTML-Documents. Zudem können alle Ausgaben bei Bedarf komprimiert werden. Im Moment macht es hier einen ganz guten Eindruck.
An der Stelle schließe ich den heutigen Artikel. Der Header ist soweit abgeschlossen. Ob es einen nächsten Teil gibt, muss ich erst einmal sehen. Eventuell fasse ich nur das bisher Geschriebene noch einmal zusammen und verlinke zu Quellen, die weiterführende Themen beschreiben. Mal schauen, was sich so ergibt.
Hi, das hast du super erklärt. Bin mal gespannt, ob ich das so hinbekomme, ohne das Theme unbrauchbar zu machen
Da mein Theme relativ viel Kram lädt, kommt mir die Maßnahme echt gelegen. Danke
Bitte sehr! Schau mal, dass Du die Sachen Schritt für Schritt änderst. Nicht alles auf einmal und immer schön durchtesten. Dann ist die Gefahr nicht so groß.
[...] von realloc Artikel #968, 10. Juli 2009 · Themes, Tipps, WordPress · 33 Kommentare · [...]
[...] Innerhalb eines Jahres sollte das auf jeden Fall machbar sein;) Interessante Ideen dafür habe ich neulich unter anderem bei Dennis gefunden, der einen schönen WordPress Blog schreibt, in dem es auch mal ans technische Eingemachte geht wie z.B. um das “WordPress Header Entschlacken“. [...]
Gibt es ein Plugin, das diese Einstellungen macht oder muss ich selber ran?
Ja, ich könnte alle vorgestellten Änderungen in einem Plugin bündeln, wenn Dir das weiterhilft. Ansonsten können die die Sachen einfach so in die functions.php. Gib einfach Bescheid, wenn Du meinst, dass ein Plugin besser wäre, dann biete ich das hier zum Download an.
Ich hab’ den Code noch einmal zusammengesammelt. Mit zwei kleinen Anpassungen in den defines am Anfang der Datei, lässt sich das Plugin so bereits benutzen, nachdem es nach /wp-content/plugins kopiert und danach aktiviert wurde.