CSS & JS richtig einbinden

Im WordPress Theme Directory immer seltener anzutreffen, in freier Wildbahn sieht man sie aber noch häufig: hardkodierte Referenzen zu CSS- oder JavaScript-Dateien im Header bzw. Footer des Themes. Es muss wohl daran liegen, dass sich einige Webdesigner nicht so richtig mit PHP anfreunden wollen und/oder aber Angst haben, da etwas falsch zu machen. Anders kann ich mir das nicht erklären.

„CSS & JS richtig einbinden“ weiterlesen

Noch mehr zu “WordPress-Themes optimieren”

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.

7. wp_head entschlacken (reloaded)

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.

8. Der „gesäuberte“ WordPress-Header

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:

<!DOCTYPE html>
<html lang=en>
  <meta charset=utf-8>
  <meta name=viewport content="initial-scale=1, minimum-scale=1, width=device-width">
  <title>Error 404 (Not Found)!!1</title>
  <style>
    *{margin:0;padding:0}html,code{font:15px/22px arial,sans-serif}html{background:#fff;color:#222;padding:15px}body{margin:7% auto 0;max-width:390px;min-height:180px;padding:30px 0 15px}* > body{background:url(//www.google.com/images/errors/robot.png) 100% 5px no-repeat;padding-right:205px}p{margin:11px 0 22px;overflow:hidden}ins{color:#777;text-decoration:none}a img{border:0}@media screen and (max-width:772px){body{background:none;margin-top:0;max-width:none;padding-right:0}}#logo{background:url(//www.google.com/images/branding/googlelogo/1x/googlelogo_color_150x54dp.png) no-repeat;margin-left:-5px}@media only screen and (min-resolution:192dpi){#logo{background:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) no-repeat 0% 0%/100% 100%;-moz-border-image:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) 0}}@media only screen and (-webkit-min-device-pixel-ratio:2){#logo{background:url(//www.google.com/images/branding/googlelogo/2x/googlelogo_color_150x54dp.png) no-repeat;-webkit-background-size:100% 100%}}#logo{display:inline-block;height:54px;width:150px}
 </style>
  <a href=//www.google.com/><span id=logo aria-label=Google></span></a>
  <p><b>404.</b> <ins>That’s an error.</ins>
  <p>The requested URL <code>/svn/trunk/examples/header.php</code> was not found on this server.  <ins>That’s all we know.</ins>

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 …

9. CSS und auch JavaScript-Datei zusammenführen

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.