WordPress optimieren Teil 1 – Der Header

WordPress als System ist in der Regel „schön einfach“, aber wer eine Reihe von Plugins installiert hat, oder diverse Features nachrüstet, der erzeugt schnell mal einen Siteload, der die Nutzer nervt, weil sie zu lange auf die Anzeige der Seite warten müssen, der aber, wie man aus vielen Einträgen in den Google-Foren der Webmastertools erfährt, auch die Suchmaschine manchmal abschreckt. Das muss nicht sein.

Wir haben uns vorgenommen eine kleine Reihe von Artikeln zu veröffentlichen, die vor allem aus unserer eigenen, jüngeren Erfahrung entspringen. Wenn man Webseiten optimieren möchte, nicht unbedingt als SEO, aber vor allem der Liebe zum Leser wegen und damit Google einen trotzdem lieb hat, kann man schon im „Kopf“ der Seite anfangen.

Template-Dateien

Wer WordPress auf WordPress.com nutzt, der müsste schon ein Pro-Package erworben haben, um ähnliche Dinge anstellen zu können, wie gleich beschrieben werden. Wer allerdings sein WordPress selbst anlegt, der kann in den Template-Dateien rumfuhrwerken.

Conditional Tags

Angenommen wir wollten ein Javascript oder eine Anweisung nur je auf einem bestimmten Seitentyp laden, und alle anderen Seiten mit den Kilobyte verschonen, die dafür geladen werden müssten. Dafür hält WordPress die Conditional Tags (kurz CT) bereit. Eine komplette Darstellung, welche Conditional Tags es gibt, findet man im Codex von WordPress (engl.).

Für die Homepage beispielsweise gibt es den CT is_home(). Handelt es sich um einen einzelnen Beitrag (Post) kann man is_single() nutzen. Dieser CT bedient allerdings auch wirklich nur „Posts“. Angenommen ihr behandelt aber „Seiten“ (Pages) und „Anhänge“ (Attachments) mehr oder weniger gleichrangig, so wie wir das tun, dann könnte für euch auch der CT is_singular() interessant sein, der nämlich alle drei Typen von Dokumenten anspricht.

Beispiel: Webfont

Wer dem Trend der Typographie im Netz folgt, der wird vielleicht früher oder später auf Webfonts zurückgreifen wollen, das sind Schriftarten, die man auf unterschiedliche Arten in seine Seiten integrieren kann. Eine kostenlose Möglichkeit ist die Nutzung von Googles Sammlung an Webfonts. Derzeit (Stand: 7. Mai 2012) kann man aus einem Fundus von 501 Schriftfamilien auswählen. Google selbst hat dort aber eine Art Tachometer angebracht, einen Anzeiger, der, je mehr Schriften man hinzufügt, immer mehr in den roten Bereich wandert. Das liegt daran, dass die Schriften erst geladen werden müssen. Je mehr Schriften, desto mehr Kilobyte muss der Browser des Nutzers herunterladen, ehe er die Schrift auch anzeigt.

Da wäre es doch effizient, wenn man nur dann wirklich alle Webfonts verwendet, wenn man sie auch wirklich braucht. In unserem Fall ist es so, dass wir auf der Homepage nur den regulären Font namens Tienne benötigen, auf den Artikelseiten allerdings zusätzlich noch den Font Lekton. Das ist übrigens die Schrift art, mit der auf dieser Seite die „Code“-Schnipsel wiedergegeben werden.

In einem ersten Schritt sollte man sich überlegen, wie man am cleversten vorgeht, um die Bedingungen zu formulieren. Dann ist es einfacher eine entsprechend Abfrage zu produzieren. „Wir“ wollen also nur in Einträgen, auf Seiten und bei Anhängen die „Code“-Schrift zusätzlich laden, auf allen anderen Seiten soll nur die normale geladen werden. Der komplette Aufruf, ohne Berücksichtigung der Seiten, würde wie folgt lauten:

<link rel="stylesheet" href="http://fonts.googleapis.com/css?family=Tienne:400|Lekton:700" type="text/css" />

Die Zeile stünde dann in der header.php. Wir wollten aber ja diese Ausgabe nur dann haben, wenn wir auf einer einzelnen Seite sind, und ansonsten auf die „Code“-Schriftart verzichten. Entsprechend würden wir den Header so umschreiben:

<?php if(is_singular()) { ?>
<link rel="stylesheet" href="http://fonts.googleapis.com/css?family=Tienne:400|Lekton:700" type="text/css" />
<?php } else { ?>
<link rel="stylesheet" href="http://fonts.googleapis.com/css?family=Tienne:400" type="text/css" />
<?php } ?>

Es bietet sich übrigens für Anfänger an, auf diese Art zu klammern:

<?php x { ?> auszuführender Code <?php } ?>

Man kann es auch anders machen, aber dann müsste man eventuell noch mit dem echo-Befehl hantieren und anstelle von einfachen Anführungszeichen, Hochkommata setzen, usf.

Mit dem oben beschriebenen Code wird erreicht, dass lediglich auf den Einzelseiten zwei Schriftarten vom Google-Server geladen werden, während aber die übrigen Seiten nur die „Standard“-Schriftart erhalten.

Beispiel 2: CSS-Dateien

Während es vor Jahren schon mal latent im Webworking den Trend gab, möglichst viele verschiedene Stylesheets zu erstellen, ist man heute wohl wieder auf dem Weg in die andere Richtung. 1 einzige Datei ist besser als 2, sind besser als 3 usw. Im Einzelfall sollte man tatsächlich den Gebrauchsfall (use case) studieren, um zu ermitteln, welche Aktion häufiger vorkommt, und dann entscheiden was Sinn macht. Beispielsweise gibt es manche WordPress-Themen, die super schöne Kommentarfelder anbieten, die aber auch enorm viel CSS-Inhalt mit sich rumschleppen. Wenn man durch das Auslagern der CSS-Formate für die Kommentare ein paar Kilobyte sparen kann, sollte man es tun. Aber auch nur dann.

Kommentare

Wenn man sich nun vorstellt, man möchte den CSS-Anteil für die Kommentare nur dann laden, wenn eine Seite auch tatsächliche Kommentare erlaubt, dann hält WordPress den CT comments_open() bereit. Eine mögliche Abfrage würde wie folgt ausschauen:

<?php if(comments_open()) { ?>
<link rel="stylesheet" href="<?php bloginfo('stylesheet_directory'); ?>/css/comments.css" />
<?php } ?>

Lightbox

Es gibt andererseits vielleicht auch die Situation, dass jemand eine Lightbox laden möchte, die unter Umständen auch noch jquery benötigt, mootools oder eine andere Javascript-Bibliothek. Es ist sehr wahrscheinlich, dass man so einen Effekt nicht schon auf der Homepage oder den Archivseiten anwendet, sondern nur in den einzelnen Beiträgen. Dann könnte man erneut zu is_singular() oder sogar nur is_single() greifen:

<?php if(is_single()) { ?>
<script type="text/javascript" src="<?php bloginfo('stylesheet_directory'); ?>/js/jquery/jquery.js?ver=1.7.1"></script>
<link rel="stylesheet" href="<?php bloginfo('stylesheet_directory'); ?>/css/lightbox.css" />
<?php } ?>

Google+-Box, Facebook, etc. pp

Man könnte noch viele Beispiele anführen. Eines aus unserer Praxis ist aber zum Beispiel die „Google Plus“-Box, bzw. die Facebook-Box, die wir lediglich auf der Startseite einfügen, aber ansonsten gar nicht. Entsprechend lautet unsere Abfrage dann wie folgt:

<?php if (is_home()) { ?%gt;
	<script type="text/javascript">
	window.___gcfg = {lang: 'en'};
	(function()
	{var po = document.createElement("script");
	po.type = "text/javascript"; po.async = true;po.src = "https://apis.google.com/js/plusone.js";
	var s = document.getElementsByTagName("script")[0];
	s.parentNode.insertBefore(po, s);
	})();</script>
<?php } ?>

Ausblick: CSS, Plugins mit Bordmitteln

Wie genau der nächste Teil ausschauen wird, haben wir uns (leider) noch nicht überlegt, aber wir wollen zumindest auch das Thema CSS noch weiter ansprechen, wenngleich die Optimierung von Stilvorlagen nicht spezifisch auf WordPress passt, sondern eigentlich jede Webseite oder jedes CMS wie bspw. Contao oder ModX betreffen. Letzteres haben wir neben WordPress auch manchmal im Einsatz.

Und in einem weiteren Schritt wollen wir thematisieren, welche Möglichkeiten man hat, auf einzelne Plugins bei WordPress zu verzichten, die man mit Bordmitteln sehr gut selbst nachbauen kann, und die einem nicht die HTML-Dateien zukleistern. Denn es gibt WordPress-Plugins, die erzeugen super viel „Overhead“. Ein schönes Beispiel hierfür wären die NextGen Gallery oder alle Plugins, die neuerdings auf die Masche gekommen sind ein „Pro“-Pack anzubieten, bei dem man dann ohne den ganzen Werbemüll auskommt, wie beispielsweise All in One SEO Pack.

Weitere Teile der Reihe Wordpress optimieren

Ähnliche Nachrichten