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.

Wenn Technologie korrumpiert wird

Zurzeit wollen die Diskussionen zur Frage, ob gekürzte Feeds irgendeinen Sinn haben, nicht abebben. Das Problem bei diesem Thema ist, dass beide Seiten Argumente haben, die irgendwie stimmig scheinen. Allerdings nur solange, wie man darüber nachdenkt, was von RSS heutzutage erwartet wird, und nicht wofür es eigentlich gut ist und welche Möglichkeiten sich beispielsweise allein durch RDF eröffnen.

Je länger ich darüber nachdenke, umso mehr schweifen man Gedanken ab. Das liegt einfach daran, dass sich mir zwangsweise Parallelen zu anderen Technologien oder Kanälen aufdrängen, die ein hartes Schicksal erleiden mussten, weil irgendwann einmal die Frage nach deren Wirtschaftlichkeit gestellt wurde. Das Kreuz mit den Erfragern der Wirtschaftlichkeit ist ja, dass sie keine Interesse an daran haben, ob etwas langfristig und nachhaltig zum Erfolg führt.

Nehmen wir beispielsweise mal HTML, das anfangs nur von den Designern kompromittiert wurde (die damit verbundenen Probleme sind auch heute noch spürbar). Aber mal abgesehen von diesem Umstand, ging es nicht bei HTML-Dokumenten ursprünglich um die Vernetzung von Informationen mittels Hyperlinks? Oder ein aktuelleres Beispiel: die Social Bookmarks. Waren die nicht eigentlich dafür gedacht, dass man seine Lieblingsseiten von jedem Computer aus nutzen kann?

Wenn man sich ähnliche grundsätzliche Fragen zu RSS stellt, erkennt man schnell, warum gekürzte Feeds komplett am eigentlichen Sinn vorbeigehen.  Die Inhalte, die in den verschiedensten Tools verarbeitet werden, sind völlig unabhängig von Problematiken, die sich durch die Wahl des Browsers oder durch die Verwendung eines bestimmten Endgerätes ergeben. Einer der großen Vorteile ist zudem, dass es völlig unerheblich ist, ob man online ist oder ob man die abonnierten Feeds einmal lädt und dann offline auf dem Weg zur Arbeit liest.

Wenn Du ein Blog betreibst und Deine Leser „nur“ über den Feed erreichst, so what? Deine Botschaft ist angekommen. Wenn es etwas zu diskutieren gibt, werden sie ganz von allein kommen. Wenn nicht, war dem vermutlich nichts mehr hinzuzufügen. Erst, wenn man nach einem Artikel auf einmal keine Feed-Leser mehr hat, würde ich mir Gedanken machen. Ach, Du hättest sie lieber direkt auf dem Blog und deshalb wird gekürzt? Warum? Damit Sie auf die Werbung klicken? Hmm, mir klingelt schon die Adblocker-Diskussion in den Ohren.

Das sind meiner Meinung nach alles Dinge, welche Online-Magazine jetzt und zukünftig mit ihren Lesern oder Kunden austragen dürfen. Da es in den Verlagen scheinbar noch an  zündenden Ideen mangelt, wie sich das Geschäftsmodell ihres Druckerzeugnisses auf das Netz übertragen lässt. Vielleicht kann man es nicht übertragen und muss eine völlig neue Vision entwickeln. Das wird nur schwierig, wenn dann wieder jemand kommt und nach kurzfristiger Wirtschaftlichkeit fragt.