• Making changes to the pages built by the Content Management Systems (CMS) with no need to make changes to the CMS itself,
• Recompressing an image when its HTML context changes to serve only the bytes required (typically tedious to optimize manually), and
• Extending the cache lifetime of the logo and images of your website to a year, while still allowing you to update these at any time.

Laut Google könnte ich nun einen 50% schnelleren Seitenaufbau haben:

We’ve seen mod_pagespeed reduce page load times by up to 50%

Aktuell registriere ich ein lahmes Backend und ein gleich schnelles Frontend – wir warten ab. Wenn etwas nicht funktionieren sollte – bitte laut schreien…. ;-)

• tweetz.tv – was schauen deinen Kollegas laut Twitter für Videos? via
• Warum steigen wir nicht einfach mal aus? (Artikel mit Tiefgang. Echt jetzt.)
• WordPress & Cache
  • Cache des Kommentarbereichs
  • Gravatar Cache
• Sex -  Na’Vi -  Fun. Nur wenn man 18 ist (YouTube-Account erford.) via

• Neda Soltani – vom Versagen der Medien und der “Social Networks”
  Must read.
• Germans protect the privacy of everything but their private parts.
  Nett zu lesen, über “uns Deutsche”. In Englisch.
• Hier noch Frauencontent. NSFW – andererseits ja auch irgendwie eine Reportage?! Grins.

Das ganze bringt zwei Vorteile mit sich:

• Die Ladezeit der Website reduziert sich aufgrund der geringeren Strecke, die Bits & Bytes zurücklegen müssen
• Der Browser lädt die komplette Seite schneller, weil der Content von verschiedenen (Sub-) Domains kommt.
  Speziell der letzte Punkt ist interessant, dies schauen wir uns nun mal genauer an.

Ein richtiges CDN bei einem großen Anbieter (wie das Amazon S3 Netzwerk) ist für die meisten Blogs ja ein wenig überdimensioniert. Also scheidet der erste o.g. Punkt am Geldbeutel und somit für den Durchschnittsblogger schonmal aus.
Aber wie sieht es mit der Auslagerung auf eine zweite (und/oder dritte) Domain aus? Bilder, CSS & Javascript ist bei jedem WordPress-Blog reichlich vorhanden, bietet sich also förmlich an.
Werfen wir einen Blick auf AskApache, wo das ganze Verfahren anschaulich dokumentiert ist:

So instead of waiting for 30 items from 1 source, it waits for 30 items from 3 different sources, drastically speeding up the transfer. By using multiple subdomains browsers are further able to maintain persistant connections with all 3 unique servers, making the site load incredibly faster.

Klingt gut.
Ich habe für den Anfang alle Bilder des aktuellen Themes, sowohl die CSS-Datei als solche auf static.gregel.com ausgelagert. Wie immer gilt: Viele Wege führen nach Rom, speziell bei WordPress.

Zum Beipiel bietet das in meiner Cache-Analyse genannte WordPress-Plugin W3 Total Cache von Haus aus die Möglichkeit CDN zu aktivieren (Über W3 Total Cache hat hombertho gebloggt, die entsprechenden Kommentare sind auch lesenswert).
Desweiteren finden sich im WordPress Plugin Directory noch einige andere Plugins speziell für diesen Zweck, z.B. CDN Rewrites oder CDN Tools.

Alle erfüllen sicherlich ihren Zweck – für mich waren sie aber entweder oversized oder suspekt. Letzteres, weil ich auch nach Studium des jeweiligen Codes nicht ganz verstanden habe, wo an welcher Stelle wie engegriffen wird – nichts für mich.

Zudem wollte ich ja klein anfangen – CSS auslagern und damit alle Bilder, die via CSS verknüpft sind. Und dies schafft man mit einfachen WordPress-Bordmitteln und drei Zeilen Code…

So verwendet jedes vernünftige Theme für das Einbinden der CSS im Head-Bereich der Seiten eine Variable:

<link rel="stylesheet" href="<?php bloginfo('stylesheet_url'); ?>" type="text/css" media="screen" />

Die Variable zielt im Normal auf domain.xy/blogverzeichnis/wp-content/themes/name/styles.css – also biegen wir dieses Ziel doch einfach um auf unsere (Sub-) Domain für statischen Content!

function stylesheet_uri_neu ($stylesheet_uri, $stylesheet) {
$stylesheet_neu_uri = 'http://static.domain.xy/dir/style.css';
return $stylesheet_neu_uri;
}
add_filter('stylesheet_uri' , 'stylesheet_uri_neu', 10, 2);

Die paar Zeilen in eine Datei name.php packen, wie jedes andere Plugin hochladen, aktivieren – fertig. Oder alternativ direkt in die functions.php des jeweiligen Themes.
Ab sofort wird die CSS-Datei und alle darin verknüpften Bilder von der neuen Subdomain geholt und unsere Seite lädt wieder ein wenig schneller.
Mission Accomplished.

Damit der Spaß an der Freude auf lange Sicht nicht zu kurz kommt, wird man im Laufe der Zeit dies und das erweitern, ändern, schrauben – und das System mit Plugins erweitern. Somit haben wir einen sehr schönen, umfangreichen, individuellen – und langsamen Blog!

Wo setzt man an? Der neuste Trend lautet Cache! Zum Beispiel mittels Plugin – Stichwort: WP Super Cache
Man sollte aber nie vergessen: Die Eierlegende Wollmilchsau gibt es nur im Märchen. Und ein Plugin um die (Geschwindigkeits-) Nachteile anderer Plugins und Konfigurationen auszumerzen hat auch schon wieder einen schalen Beigeschmack.
Nichtsdestotrotz einen Blick wert – später!
Bevor man auf Plugins zurückgreift und versucht via Knofpdruck zu optimieren, kann man selbst auch einiges erreichen.

Ein guter Anfang für eine Analyse und Optimierung ist ein Online-Test wie Pingdom.
Neben der Gesamtladezeit der Seite bekommt man einen netten Einblick in das, was bei jedem Seitenaufruf geladen wird – und das kann schonmal erschreckend sein.
Spätestens jetzt wird klar, dass Plugin-Entwickler es lieben, eigenen CSS und JS in dem Header mit auszugeben.

Zeit für eine erste Analyse: Wofür brauche ich genau das Plugin?
Ein Beispiel von mir. Seit ewigen Zeiten habe ich den Download Monitor als Plugin verwendet. Überaus nett um Dateien zu verwalten und zum Download anzubieten, incl. Statistik. Auf ein stolzes Dutzend Downloads bin ich gekommen. Dafür ein extra CSS und JS bei jedem Seitenaufruf laden? Nein danke. Rausgeflogen.

Oft will man aber auf ein Plugin nicht verzichten, dass eigenes CSS oder JS lädt. Schonmal einen intensiveren Blick in die Optionen des Plugins geworfen? Einige (leider noch nicht viele) bieten die Möglichkeit an, Einstellungen zum CSS zu machen.
Zum Beispiel die NextGen Gallery, auf die ich ungern verzichten würde. Sie bring eine Menge CSS mit – aber mit einem Mausklick kann man das (separate) laden unterbinden und stattdessen den betreffenden Code in die styles.css des verwendeten Themes einbinden. Wieder ein Ladevorgang weniger – bei jedem Seitenaufruf.

Irgendwann sind diese Möglichkeiten – wenn man nicht einen gewaltigen Aufwand betreibt – erschöpft. Kommen wir also zu dem spannenden Thema Cache, in all seinen Varianten.

Seit einiger Zeit hatte ich die Verknüpfung von eAccelerator mit dem WordPress Object-Cache hier im Einsatz, nach einer Anregung von Frank Bueltge – eAccelerator für WordPress. Die Ergebnisse können prinzipiell überzeugen, die einzelnen Datenbankabfragen gehen richtig in den Keller.
Leider ist der Code, bzw. die Code-Grundlage nicht mehr die neuste. Folglich gibt es einige Einschränkungen – bei mir im Backend funktionierte z.B. die Prüfung auf aktualisierte Plugins nicht mehr ordentlich. Die rote Zahl, die mit in der “Plugin-Navigation” immer ein Update ankündigte, blieb aus.

Eine weitere Version, die den WordPress-Cache mit eAccelerator verbindet, kann man ebenfalls probieren. Die Ausgangsbasis ist gleich, nur…

At the time of writing, the NeoSmart eAccelerator backend is old and doesn’t work nicely with the latest versions of WordPress. Specifically; it doesn’t implement the non-persistent groups. Caching these objects in a persistent fashion (longer than the current page view) results in some rather odd behaviour.

Einen Test ist dieser Object-Cache allemal wert.

Es gilt jedoch nicht immer: Cache = schneller
Darauf weisst auf der Coder selbst hin. Eine WordPress-Installation, die einen Server (natürlich mit eAccelerator) halbwegs für sich hat, die einen gut konfigurierten Mysql eigenen Query-Cache nutzt, wird in Verbindung mit dem Object-Cache ggf. langsamer im Seitenaufbau sein! Bei mir ist dies z.B. der Fall…
Die Anzahl der Queries auf die Datenbank geht stark zurück – dies schlägt sich aber nicht direkt in einem schnelleren Seitenaufbau wieder! Ausprobieren, testen, auswerten…

Optimierung ist individuell!

Wer jetzt noch nicht ganz den Pfaden und die Lust auf Optimierung via Cache verloren hat, dem empfehle ich noch ein weiteres Plugin. Basierend auf dem oben bereits genannten WP Super Cache Plugin:
WordPress Super Cache Plus

Die angelegten statischen html Seiten werden nicht mehr (wie beim Original) auf der Festplatte abgelegt, sondern es wird RAM genutzt.
Neben meinem Favoriten – eAccelerator – stehen APC, XCache, Zend-Cache und Memcached zur Verfügung.

Der Seitenaufbau ist mit dieser Lösung wirklich brutal schnell. Aber auch hier die Schattenseite: Will man wirklich statische Seiten ausliefern?
Für mich lautet die Antwort nein, aufgrund der Inkompatibilität von statisch gecachten Seiten mit meinem Landingsites-Plugin für SuMa-Besucher.
Diese begrüße ich lieber individuell, als schnell.

Ich wiederhole mich, Optimierung ist individuell. Jeder muss für sich abwegen, wo die Prioritäten gesetzt werden. Die Möglichkeiten sind in jedem Fall (fast) unendlich.
Die o.g. Möglichkeiten setzten natürlich woraus, dass man ein gewisses Grundwissen über Server, php, sql… hat. Oder eine gewisse Abenteuerlust :-)

Zu guter letzt noch ein Tip:
Für alle, denen Super Cache zu langweilig ist, Super Cache Plus zu gewagt…
W3 Total Cache ist auch noch einen Blick wert. Das tue ich nun in den kommenden Tagen – und werde sicherlich berichten… ;-)

Update: Ich sehe gerade, hombertho hat heute etwas zu W3 Total Cache geschrieben!