WordPress Ladezeiten drastisch verkürzen!

WordPress ist für viele Blogger die erste Wahl, wenn es um die Auswahl der Bloggingsoftware geht. Doch ein großer Nachteil von WordPress ist, dass es nach einiger Zeit durch den Ausbau mit Plugins zu überladen und zu schwerfällig wird. Dessen nicht genug, lässt WordPress bei hohen Besucherzahlen häufig den Server abrauchen. Wer da keine leistungsfähige Maschine hat, kann schnell in Bedrängnis kommen. Besonders schnell kann diese Situation auftreten, wenn die Seite nur auf einem günstigen Domainpaket läuft, bei welchem der Server noch mit weiteren 50 Kunden geteilt wird.

Die Ladezeit einer Seite ist dabei nicht nur ein Qualitätsmerkmal für echte Besucher, sondern auch für Suchmaschinen. Je schneller eine Seite lädt, desto mehr mag euch auch Google etc. Das bedeutet zwei Fliegen mit einer Klappe schlagen: Mehr Besucher durch geringere Ladezeiten so wie eine niedrigere Absprungrate und SEO vom Feinsten! Es gibt allerdings mehrere Möglichkeiten, um lange Ladezeiten und Performance zu schonen. Und diese – welch Überraschung, werde ich jetzt nennen!

1. Unnötige Dateien nicht laden lassen

Alle Dateien, die die aktuell aufgerufene Seite nicht braucht, sollten nach Möglichkeit auch nicht mitgeladen werden. Um dies zu erreichen ist etwas PHP-Wissen vorteilhaft.

Einfachste Lösung wäre, einfach eine Kategorie zu erstellen, die man nicht ausgibt und anschließend mit einer Abfrage á la

if ( in_category('<em>kategoriename</em>') ) { add_action( 'wp_head', '<em>funktionsname</em>' ); };

in die Plugindatei einzufügen. An welcher Stelle und wie man diese Zeilen findet, wird etwas ausführlicher in Punkt 2 erläutert. Ich werde mal schauen, ob es hier noch eine schönere Lösung gibt und sage euch dann Bescheid Ich meine aber, es gab da was.

2. Scripts in den Footer verlegen

WordPress Themes haben für gewöhnlich zwei “Ankerpunkte” für Scripts, Metaangaben und andere Werte, die man so einbinden möchte (z.B. Scripts, Suchmaschinentags, etc.), einmal im Header des Themes () und einmal im Footer (kurz vor ). Diese Funktionen sind mit und definiert. Viele Plugins benutzen diese Funktionen, um ihre Plugineigenen Scripts, Stylesheets, etc. im Theme auszugeben. Und die meisten dieser Plugins, die das machen, lassen die Scripts mit ausgeben, was bedeutet, dass die Scripts meistens geladen werden, bevor die Seite selbst geladen wird.  Dies ist natürlich ein höchst unschöner Umstand, denn der Surfer muss nun erst alle Scripts runterladen, ehe die Ausgabe der eigentlichen Seite überhaupt anfängt.

Es gibt aber auch die Möglichkeit, die Scripts in den Footer zu verlagern:

1. Man entfernt einfach aus dem Header und packt es kurz vor das -Tag am Ende des Themes hin. Dies ist aber eine etwas unelegante Methode und nur im Notfall zu empfehlen, da durch durchaus auch sinnvolle Informationen ausgegeben werden, die am Ende der Seite völlig fehl am Platz sind (ich bin mir gerade nicht sicher, aber das Plugin robots meta z.B. müsste seine Angaben durch diese Funktion ausgeben, welche nun auch wirklich nur in den -Bereich einer Seite gehören).
2. Man pflanzt die großen Scripts der Plugins manuell in die andere Funktion ein. Dies ist immer sehr zu empfehlen. Es macht vor allem Sinn bei Plugins wie z.B. Lightbox 2 – denn der User wird die Seite bestimmt nicht besuchen um noch bei ungeladener Seite sofort zum nächsten Bild zu “laufen” und dieses mit den erwartungsvoll leuchtenden Augen eines Kindes anklicken, in der Hoffnung dass sich eine Lightbox öffnet.

Zur ersten Methode muss ich glaube ich nicht allzu viel sagen, das müsste klar sein (das soll jetzt auch kein HTML-Tutorial sein, wenn ihr also nicht wisst, was der -Tag ist oder sonstiges, fragt einfach mal in einem Webdesignerforum nach oder schaut euch bei selfhtml um).

Zur zweiten Methode: Dafür müsst ihr leider ein wenig Code eurer eingesetzten Plugins bearbeiten. Dies ist im Grunde nicht schwierig, aber ein Texteditor, mit dem man große Dateien nach Zeichenfolgen durchsuchen kann (normale Textsuche) sollte reichen. Ich mag ganz gerne Notepad2, aber im Grunde ist es Geschmackssache. Naja, wie gesagt: Ein wenig Know-How und ein geübter Blick könnten durchaus von Nutzen sein.

Zuerst schaut ihr euch den Quelltext eurer Seite an (besonders im Kopfbereich) und schaut euch an, welche Dateien von Plugins eingeladen werden (diese Dateien sehen fast immer so aus: <script type=”text/javascript” src=”http://www.euredomain.de/wp-content/plugins/*pluginname*/script.js”></script>. Nun müsst ihr nur noch nach dem Pluginordner suchen.).

Zumeist findet man gesuchte Zeilen in der Hauptdatei des Plugins. Wenn es etwas größer ist, braucht man ein gutes Gespür um herauszufinden, in welcher Datei die betroffenen Zeilen stehen (Tipp: häufig ist es in der größten Datei oder der Datei im Hauptverzeichnis des Plugins zu finden, welche den gleichen Namen wie das Plugin trägt). Und hier ist wonach ihr Ausschau halten müsst:

add_action('wp_head', '<em>funktionsname</em>' );

Dabei kann funktionsname sonstwie aussehen. Die Funktion selbst ist dann meistens in der näheren Umgebung zu finden. Wenn nicht, hilft wieder die Textsuche des Editors. Einfach nach funktionsname suchen und ihr werdet die besagte Funktion schnell finden. Achtet dabei darauf, dassdie Funktion auch ein Script enthält, welches sie eigentlich einbindet (möglicher Anfang: echo “<script type=”text/javascript” [...]“). Wenn ähnliches drin steht, habt ihr alles richtig gemacht. Ändert nun das wp_head in der oberen in wp_footer, so dass es im Endeffekt folgendermaßen aussieht:

add_action('wp_footer', '<em>funktionsname</em>' );

Nun wird das Script im Footer eingebunden (vorausgesetzt in eurem Template ist die Zeile <?php wp_footer(); ?> verbaut). Ihr müsst allerdings probieren. Manche Scripts müssen vor ihrem Ausführungsort eingeladen werden. Wenn euer Plugin hinterher also nicht mehr funktionieren sollte, bleibt euch nichts anderes übrig, als die Änderungen rückgängig zu machen

3. Stylesheets in einer zusammenfassen

Viele Plugins binden noch ihre eigenen Stylesheets ein. Dann muss der Client etliche Stylesheets aus sämtlichen Pluginordnern ziehen. Das ist absoluter Mist. Alles was ihr wieder machen müsst, ist den Inhalt der eingebundenen Stylesheets (ähnlich zu erkennen wie die eingebundenen JavaScripts) einfach kopieren und in eure Hauptstylesheet einfügen. Anschließend führt ihr die Prozedur wie bei Methode 2 von Punkt 2 noch einmal durch, nur dass ihr diesmal auf auf die Zeilen achtet, die mit <link rel=”stylesheet” href=”[...]/stylesheet.css” type=”text/css” /> achtet.

Nachdem ihr wieder die Plugindatei rausgesucht habt, sucht ihr wieder nach wp_header, in der Nähe müsste wieder die Funktion sein, die die Stylesheetausgabe steuert. Wenn die Funktion nichts anderes macht, als nur die Stylesheet auszugeben (ohne weitere JavaScripts) könnt ihr die Funktion einfach löschen ( add_action(‘wp_head’, ‘funktionsname’); ebenfalls löschen!!)). Wenn ihr den Inhalt der Pluginstylesheet wie bereits angeordnet, in eure eigentliche Styledatei kopiert habt, wars das!

4. weniger und kleinere Dateien einbinden

Jede einzelne Datei, die der Server ausliefern muss, kostet ihn Performance und Arbeitsspeicher. Je mehr Grafiken, desto mehr Probleme zieht das also hinter sich her. Der gleiche Fall ist auch bei Stylesheets und JavaScripts. Versucht also Stylesheets von Plugins nicht zu benutzen, sondern alle nötigen Styles im Hauptsheet unterzubringen. Das gleiche könnt ihr auch mit JavaScripts machen, allerdings muss man hier bereit sein, Kompromisse einzugehen. Wenn ihr z.B. alles JavaScript in eine einzige Datei tut, wird die Sache sehr problematisch, da die Datei schnell astronomische Größen einnehmen kann. Dabei werden vielleicht gar nicht bei jeder Seite alle Funktionen benötigt. Ihr solltet also selber wissen, was euch wichtiger ist: eine größere JavaScript-Datei (empfohlen bei nicht allzu vielen JavaScript-Spielereien auf der Seite, die außerdem recht regelmäßig eingebunden werden müssen) oder mehrere kleinere (was eine längere Auslieferung bedeutet, dafür aber eine kürzere Ladezeit der Dateien selbst, weil weniger Bits und Bytes geladen werden müssen).

Auch bei Grafiken könnt ihr hier enorme Performance einsparen. Wer gerne .png-Dateien verwendet (so wie ich ), sollte sich einmal dennoch zu .jpeg-Dateien umentscheiden, sofern keine Transparenz oder ähnliche Voraussetzungen erfüllt sein müssen. Hier liegen oft riesige Einsparungsmöglichkeiten vor.

5. Cachen

Das Cachen der Seite entlastet hauptsächlich die MySQL-Datenbank vor Arbeit so wie die Verarbeitung mit PHP unmittelbar vor der Ausgabe. Man sollte immer das Plugin WP SuperCache installiert und einsatzbereit haben, damit man es bei auftretenden Schwierigkeiten nur noch einschalten sollte. Diese Methode entlastet den Server ungemein.

Beim Cachen als eine der effektivsten Arten der Leistungseinsparung ist man aber auch gezwungen, Opfer zu bringen: So gehen beim Cachen die dynamischen Inhalte flöten.

6. Möglichst wenig Fremddateien einbinden.

Ganz einfach: Bindet keine Drittanbieterscripte ein (ich persöhnlich beschränke mich bei Drittanbieterscripten nur auf Google Analytics, alles andere wird bei mir gehostet). Denn ihr habt keinen Einfluss darauf, wie überlastet der Server des Drittanbieters gerade ist, ob er ganz down ist, wie schnell er sonst ist, etc. Im schlimmsten Fall kann es bei der Einbindung von Scripts im oberen Teil der Seite sogar passieren, dass eure Seite gar nicht mehr aufgerufen wird (sind aber nur spzielle Fälle)

7. Sauberer Code, nach Möglichkeit auch komprimiert

Erst einmal sollte man dafür sorgen, dass das XHTML des Blogs keine unnötigen Bauten aufweist, ebenso beim Stylesheet (und JavaScript). Wenn man sich dessen sicher ist, kann man anschließend noch das Sytlesheet und die JavaScripts noch weiter schrumpfen, ohne dabei inhaltlich irgendwas zu verändern.

Wie das geht? Jede Datei besteht aus Zeichen. Dabei darf man nicht vergessen, das auch Textumbrüche und Leerzeichen als Zeichen angesehen werden und Speicherplatz einnehmen (und Kommentare selbstverständlich auch. Sie haben ja zumeist keinen Einfluss auf den Code. Allerdings sollte man hier vorsichtig sein, weil zumindest das WordPress Stylesheet style.css einen Kommentar an oberster Stelle haben muss). Man sollte also alles, was nicht für den Code relevant ist, streichen. Um das nicht von Hand machen zu müssen, gibt es dafür einige gute Tools, ich bevorzuge dafür das Compress Tool von Sergej Müller. Allerdings ist hier Vorsicht angesagt: Manche Tools zerstückeln manchmal bei zu hohem Grad der Komprimierung den Code!

8. Mehrere Domains zum Laden benutzen

Browser sind in der Lage, bis zu einer besitmmten Anzahl an Verbindungen gleichzeitig aufnehmen zu können (wieviele Verbindungen das sein können, hängt vom Browser selbst ab und dessen Einstellungen. Faustregel ist jedoch: Mindestens 8 Verbindungen sollte ein jeder Browser gleichzeitig aufnehmen können). Dies hat den Vorteil, dass der Browser nicht jede einzelne Datei einzeln herunterladen und warten muss, bis der Server die nächste Datei schickt, sondern parallel Dateien laden kann. Warum dies überhaupt ein Vorteil ist? Weil der Server manchmal bei großer Auslastung nicht mit der Geschwindigkeit zum Clienten “hochladen” kann, wie der Client die Dateien downloaden kann. Um diese Ressourcen abzudecken, sollte man mehrere Domains benutzen.

Mit Domains meine ich übrigens Subdomains. Erstellt einfach eine Subdomain á la http://bilder.domain.de oder http://javascripts.domain.de und gebt den Pfad zu den Dateien zu eben diesen auf den Subdomains gespeicherten Dateien aus. Somit bindet ihr wieder keine Drittanbieter ein, habt aber auch einen hübschen Geschwindigkeitsschub.

9. Warten und updaten

Zeit heilt Wunden. Auch hier ist es so. Jedes Update – ganz gleich ob WordPress oder Plugin – , welches euer System erfährt, schont in der Regel euren Server. Dies ist aber nicht nur Systemintern, sondern kann auch beim Server selbst zutreffen. WordPress baut auf PHP und dieses wird kontinuierlich weiterentwickelt. Die erwartete Version 5.3 soll etliche Performance einsparen und eure Seite schneller laden lassen. Bugfixes, Optimierungen und vieles mehr bringen solche Updates immer. Ähnlich ist es mit der MySQL-Entwicklung. Allerdings könnt ihr selbst nur in den seltensten Fällen diese Software selber updaten, meistens macht dies euer Hoster. Aber ihr könnt ja ab und zu auf php.net oder mysql.com vorbeischauen und gucken, welche Version gerade die aktuellste ist. Wenn bei euch eine veraltete Version läuft (nachsehen könnt ihr das z.B. mit diesem Plugin), solltet ihr also den Hoster darum bitten, mal die Pakete zu aktualisieren.

Was noch?

Wie siehts aus, habt ihr noch weitere Vorschläge / Ideen? Oder funktioniert einer meiner Vorschläge vielleicht nicht? Immer her damit