Startseite » QR-Code für diese Seite

WordPress: Performance optimieren – 13x mehr…

23 Februar 2011, 14.580x angezeigt, 9 Kommentare
Tags: , , , , , , , , , ,

In den letzten Wochen habe ich mich vermehrt mit Performance von WordPress beschäftigt, weshalb ich nun mein Wissen einmal zusammenfassen wollte. 360friends.de baut selbst, wie man im ersten Artikel lesen konnte, auf WordPress auf. Damit das Surfen auf einer Webseite möglichst angenehm und benutzerfreundlich ist, sollte eine Webseite im Aufbau so schnell wie möglich sein. Wir Webentwickler, alle wahrscheinlich mit Firefox unterwegs, sind einen langsamen Aufbau einer Webseite teilweise schon fast gewohnt, wenn man das Rendering vom Firefox mit Safari vergleicht. Da dies aber Browser spezifisch ist und oftmals mit zahlreichen AddOns in Verbindung steht, suchen wird andere Möglichkeiten die Webseite serverseitig zu beschleunigen.

Die zahlreichen Tipps & Tricks bzw. Erklärungen in der Liste können separat angewendet werden um die Performance des Systems im allgemeinen zu verbessern. Die Reihenfolge ist nicht zu bewerten! Aber fangen wir erst einmal mal an…

1. Plugins prüfen

Wie in jedem System, bremst jede installierte Erweiterung eine Applikation immer mehr aus. Dieses verhalten ist bei eurem Browser (z.B. Firefox) genauso anzutreffen wie in eurem WordPress. Oft sind Plugins (und auch Themes) installiert oder vorhanden welche nicht (mehr) benötigt werden und/oder Ressourcen verschwenden. Der erste Schritt sollte sein, nicht benutze Plugins und Themes zu deaktivieren und auch vom Server zu löschen. Das Löschen trägt nebenbei zur Sicherheit bei, weil auch über fehlerhafte deaktivierte Plugins ein Einbruch in das System möglich ist. In einem weiteren Schritt, solltet ihr die Plugins der Reihe nach deaktivieren, Ressourcen prüfen und wieder aktivieren. Dadurch lassen sich Ressource-Fresser finden. Findet ihr solche Ressourcen-Fresser hilft es den Autor zu kontaktieren und auf einen Fix zu warten oder aber nach einer Alternative zu suchen (Vielleicht auch selbst weiter suchen um das Ressource Problem zu finden).

2. Header „flush“

PHP bietet mit dem „flush“-Befehle, welchen es seit PHP4 gibt (Doku), die Möglichkeit die bereits generierte Ausgabe zum Client zu senden. Dadurch lässt sich ein wenig Rechenzeit parallelisieren weil der Client schon mit dem Rendering des Header anfangen kann (Ressourcen nachladen), während der Server noch den Body generiert.

Ich empfehle den flush-Befehl an dem Ende der header.php eures Themes einzugeben. Dadurch wird der Header auf allen Seiten immer direkt geflusht unabhängig ob es zum Beispiel eine 404-Error oder eine Post-Seite ist. Der Performance-Zuwachs war für mich nicht direkt messbar.

3. Revisionen ausschalten

Seit der WordPress Version 2.6 speichert WordPress Änderungen und hält diese vor. Dies geschieht immer wenn man einen Post sichert (aber auch das automatische speichern gehört dazu). Die Revisionen findet man dann ganz unten auf der Post-Editieren-Seite. In der „wp-config.php“-Datei kann die Funktion ausgeschaltet oder wenigstens limitiert werden, damit die Datenbank nicht voll läuft. Das Volllaufen der Datenbank geht gerade bei den Posts schnell, an denen sehr lange gearbeitet wird/wurde. Folgender Eintrag in die Konfigurationsdatei schaltet die Revisionen ab:

define(‚WP_POST_REVISIONS‘, false);

Ich empfehle euch anstatt dem „false“ einen Zahlenwert zwischen 3 und 5 zu benutzen. Dadurch werden immer x Revisionen aufbewahrt und ältere automatisch gelöscht. So nimmt man sich nicht komplett die Möglichkeit etwas rückgängig zu machen und dennoch läuft die Datenbank nicht unkontrolliert voll. Top!

4. Ausgabe komprimieren

Die Ausgabe von WordPress sollte für die Datenübertragung komprimiert werden. Dadurch können die Daten schneller durchs Netz geschickt werden und das komprimieren und dekomprimieren ist vergleichsweise simple. Eine Möglichkeit ist das Plugin wpCompressor, welches die Komprimierung vollständig übernimmt. Das Plugin muss noch nicht einmal konfiguriert werden :)

5. Aktuellst Version benutzen

Viele haben Angst immer die aktuellste Version von WordPress zu benutzen, weil sich ein Fehler eingeschlichen haben könnte und im Endeffekt funktioniert ja alles. „Never change a running system!“. Jedoch werden relativ häufig bei neuen Versionen von Online Applikationen (kenne das auch von TYPO3) Optimierungen und Verbesserungen für die Performance eingearbeitet. Somit bietet eine aktuelle WordPress Version neben neuen Funktionen oft auch mehr Performance und eine bessere Stabilität.

6. Datenbank-Abfragen reduzieren

Die MySQL Datenbank welche hinter WordPress läuft, hat natürlich, gerade bei großen Blogs, jede Menge zu tun. Deshalb hilft es oft, schon wenige Queries zu optimieren bzw. zu reduzieren. Die Anzahl der Queries kann man sich einfach mit einem Einzeiler im Template ausgaben lassen oder ein Plugin dafür benutzen(z.B. Debug Queries von Frank):

<?php echo $wpdb->num_queries; ?>q, <?php timer_stop(1); ?>

Normale Queries

In einem Beispiel will ich euch veranschaulichen was es bedeutet eine normale Query zu optimieren bzw. normale Queries zu reduzieren:

Vorher: Codestrecke welche zu 7 SQL abfragen führte

Vorher: Codestrecke welche zu 7 SQL Abfragen führte

Die Codestrecke welche Ihr im Screenshot seht führt sieben SQL Queries aus. Das liegt daran, das die Posts nicht über die WordPress Standard Funktion selektiert werden, sondern von Hand. Wird nun die get_permalink Methode aufgerufen, muss für die Link Generierung erneut eine Query abgeschickt werden, weil die benötigten Daten WordPress fehlen. Deshalb habe ich die Zeilen im Template umgeschrieben…

Nachher: nur noch 3 Abfragen werden durchgeführt

Nachher: nur noch 3 Abfragen werden durchgeführt

Für die Selektion der Posts wird nun die Standard Funktion get_posts benutzt. Diese selektiert natürlich deutlich mehr Daten, jedoch fallen die zusätzlichen Datenbank Abfragen innerhalb der foreach-Schleife nicht mehr an. Die Code-Strecke konnte von 7 auf 3 Queries reduziert werden. Glaubt mir wenn ich euch sage, es gibt viele solche Stellen. BTW: Es wird gleichzeitig an der Übersichtlichkeit des PHP Code geschraubt :)

Optionen prüfen

Optionen sind Einstellungen welche normalerweise zu Beginn des Ladens einer Seite im Blog mit geladen werden. Viele Optionen werden in einer zentralen Abfrage direkt ermittelt, wenn der Datenbankwert „autoload“ auf „yes“ steht. Hier gibt es nun zwei Dinge die optimiert werden können. Erstens kann es sein das bei jedem/vielen Seitenaufrufen ein und der selbe Optionswert immer wieder „nachgeladen“ wird. Macht euch nichts d’raus und setzt die Eigenschaft „autoload“ der Option in der Datenbank auf „yes“. Der Wert wird dann schon bei der Initialisierung selektiert und die weitere Abfrage ist Geschichte.

Ein andere Punkt ist vielleicht der, dass das Plugin eine Konfigurationsseite hat welche noch nie gespeichert wurde oder das Plugin gar keine Möglichkeit bietet die Option zu setzen. Wenn ein Optionswert nicht in der Datenbank liegt, wird dieser vom Plugin nochmal angefragt (Er konnte ja beim initialisieren nicht selektiert werden). Das Plugin merkt dann, das es die Option nicht gibt und fällt auf einen Defaultwert zurück. Ich hatte diese Phänomen z.B. bei WP Widget Cache. Die Lösung war, einfach einmal die Konfiguration zu speichern, weil die Extension dann alle Optionen angelegt hat. Und siehe da… wieder 3 Queries weniger. Prüft dies am Besten mit dem Debug Queries Plugin (siehe oben)

7. Bilder optimieren

In der Mediathek wird angezeigt wie stark das Bild kleiner gemacht wurde.

In der Mediathek wird angezeigt wie stark das Bild kleiner gemacht wurde.

Das Optimieren der Bilder kann man einerseits von Hand machen, es gibt zum anderen aber auch viele Dienste die das Online durchführen. Der wohl bekannteste Dienst hierfür ist smushit.com, für den es auch eine WordPress Integration gibt, welche auf den Namen „WP Smush.it“ hört. Ist das Plugin installiert, rechnet es die Bilder automatisch nach dem Upload kleiner. Alternativ kann man den Optimierungsprozess auch von Hand in der Mediathek anstoßen. Hinweis: Es gibt keinen sichtbaren Qualitätsverlust! Also schaden kann es bestimmt nicht. Hier geht es zum Plugin.

8. Theme validieren

Es ist in vielen Browsern so, dass die Seite schneller aufgebaut wird, wenn der Themen gegenüber des mitgelieferten Doctype validiert. Neben dem Eliminieren von Kompatibilitäts-Problemen zwischen Browsern, kann dies auch die Rendering-Zeit im Browser selbst erhöhen. Bei invaliden Seiten könnte der Browser auch in einen Quirks Modus fallen (darauf achten das ihr einen Doctype habt). Diesen Modus sollte man einerseits wegen der Performance anderseits wegen der Kompatibilität vermeiden.

9. Cache Plugins benutzen

Für WordPress gibt es eine Vielzahl an Cache Plugins. Die wichtigsten möchte ich euch einmal kurz vorstellen.

Normaler Cache

Normale Caches können via WordPress API in jedes Plugin inkludiert werden. Neben dem WordPress internen Cache gibt auch noch eine Möglichkeit die Seite komplett statisch auszuliefern. Das WP Super Cache Plugin nutzt mod_rewrite um die User auf eine statische html-Datei zu leiten. Dadurch wird der PHP-Interpreter nicht geladen, welcher einen großen Teil des Overheads ausmacht. Das Super Cache Plugin kümmert sich um das Aktualisieren der Caches und das Kommentare und Passwort-geschützte Seite passend behandelt werden. Diesen Cache benutze ich hier selber nicht, weil es noch ein paar dynamische Dinge auf der Seite gibt.

Wordpress Widget Cache

WordPress Widget Cache

Widget Cache

Der Widget Cache hat einen ähnlichen aber dennoch anderen Ansatz. Der Cache speichert jedes Widget mit einer eigenen Konfiguration in einer separaten HTML Datei. Mittels der Konfiguration (siehe Screenshot) kann jedem Widget eine Cache-Dauer gegeben werden. Zusätzlich werden die passenden Caches gelöscht sobald ein bestimmter Datentyp manipuliert wurden (z.B. ein neuer Kommentar).

Ich benutze diese Cache sehr ausgiebig und habe sogar teile der Theme-Logik auf Widgets umgestellt, damit der Cache dort auch funktioniert. Nach der Einführung des Caches konnte ich die Sitebar-Queries von 9 auf 3 reduzieren und die Footer-Queries von 8 auf 0. Zudem generiert die Seite ca. 15% schneller. Mehr Informationen zu diesem Cache gibt es auf der Autor-Seite des Plugins.

10. Externe „static“-Domain benutzen

Es ist empfehlenswert statische Inhalte auf eine externe Domain auszulagern. Auf diesen Domains kann man dann z.B. die Cookies deaktiviere, was Traffic spart, und spezielle Header schicken, sodass alle Dateien optimal gecached werden. Am Besten ist ein Expires-Header, welcher weit in der Zukunft liegt, sodass die Datei von einem Client gar nicht mehrfach angefragt wird. Schlagworte wie GZip und Minify sind hier auch interessant (Siehe Punkt 13).

Die Steigerung dieser Umstrukturierung wäre z.B. ein CDN.

11. DNS Abfragen vermeiden

Von jeder Domain von der auch Daten bezogen werden, muss die IP ermittelt werden. Diese Ermittlung kostet Zeit und ist oftmals überflüssig. Ihr solltet darauf achten, das eure gesamte Webseite von wenigen Domains geladen wird, damit unnötige DNS Anfragen das Laden nicht ausbremsen.

Prüft dazu euren Theme, weil in diesen gerne Javascript Bibliotheken von zentralen Ordner geladen werden. Zudem können externe Dienste auf dem eigenen Server zwischengespeichert werden. Dies geht z.B. mit Gravatar was bei playground.ebiene.de vorgestellt wurde. Diese Art von Cache reduziert einerseits die DNS Abfragen anderseits überbrückt es kurze Ausfälle der externen Dienste.

12. Prüfe YSlow und/oder Google Page Speed

Nachdem wir nun schon einige Optimierungen hinter uns gebracht haben, ist es mal Zeit ein Tool zur Hilfe zu nehmen. Ich empfehle YSlow von Yahoo oder Page Speed von Google. Beides Tools laufen z.B. im Firefox als Client und ergänzen den Firebug um die Analysefunktionen die wir brauchen. Man bekommt während dem Seitenaufbau ausgiebige Informationen über Inhalte und Dateien und eine gute Zusammenfassung. Empfehlenswert.

13. In eigener Sache: Static Web Speed

Für viele der oben genannten Punkte habe ich ein Script entwickelt was sich um viele der Punkte kümmert. Auf der Domain staticwebspeed.com habe ich erste Ergebnisse zusammengetragen. Im Moment suche ich nach weiteren Ideen und Entwicklern, damit sich das Projekt weiter abrundet. Die Webseite soll im Moment der Inspiration dienen. in kürze werde ich weitere Ideen vorstellen.

Fazit

Ich habe alle Maßnahmen für diesen Blog durchlaufen. Manche bringen mehr und Manche weniger Leistung für die Ladegeschwindigkeit. Tatsache ist jedoch, das sowohl die Messungen der Ergebnisse als auch das Empfinden des Ladeprozesses deutlich besser ist. Ich empfehle jedem Blogger, aber auch normalen Webmastern dazu, die Punkte zu beachten, damit das surfen im Web Spaß macht.

Inspiriert wurde ich bei dem Listing oben u.a. durch folgende Quellen, vielen Dank!:

Ich hoffe euch gefällt die Zusammenstellung, von der einige Punkte WordPress spezifisch sind, andere aber auch auf normale Webseite zutreffen. Habt ihr noch weitere Ideen und Möglichkeiten die Performance zu verbessern? Lasst es mich wissen und ich werde das unter die Lupe nehmen!

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInPin on Pinterest
Tim Lochmüller Autor
Name: Tim Lochmüller
Webseite: http://typo3blogger.de
Posts: 201 Posts

9 Kommentare »

  • Selber Apps Entwickeln? - Performance, Artikel, WordPress, Grad, Butze, BlackBerry® - Die Datenreisenden
    Selber Apps Entwickeln? - Performance, Artikel, WordPress, Grad, Butze, BlackBerry® - Die Datenreisenden sagt:

    […] Bereits damals habe ich hier einen Artikel veröffentlich, wie man doe WordPress Performance erhöhen kann, da die Welt nicht schläft und sich alles weiter entwickelt, findet man nun eine sehr schöne Zusammenfassung sämtlicher bekannten Tricks für mehr Performance mit WordPress bei 360friends.de. […]

  • Holger
    Holger sagt:

    13x schneller halte ich eher auch für ein Gerücht… soweit es mir Möglich war habe ich auch alles Mal überprüft und umgestellt. Mein Fazit ist es eine klare Geschwindigkeitssteigerung zu erkennen ist und es der Aufwand alle male wert ist!

    Gruß Holger

  • Tim Lochmüller
    Tim Lochmüller (Autor) sagt:

    Da muss ich dir natürlich recht geben … die 13 bezog sich mehr auf die Headlines im Beitrag ;) Dennoch hilft vieles enorm. Vieles, gerade die Static Domain und hohe expires headeres, merkt man natürlich beim surfen stark… gerade wenn man eine menge Seite aufruft. Wenn du noch weitere Ideen hast, dann ergänze ich gerne das Listing. Grüße, Tim

  • maggy
    maggy sagt:

    holger, da stimm ich dir voll zu, der aufwand lohnt sich! gruß, maggy

  • Marcel
    Marcel sagt:

    Hallo, ein interessanter Punkt über den ich mal „laut“ nachdenken werde ;-)

  • Christian
    Christian sagt:

    Hallo Tim,

    mit Interesse habe ich Deine Liste gelesen. Gekommen bin ich über Google auf Deine Seite, weil ich auf der Suche nach Tipps war, was ein adequate ‚time-to-first-byte‘-Wert der Testtools ist. Ist mein Provider langsam oder ist es mit WordPress nie richtig schnell.

    Dazu fehlen mir leider immer noch jegliche Erkenntnisse. Kommt man beim webpagetest.org überhaupt besser als C weg?

    Erschreckend finde ich aber das webpagetest.org-Ergebnis genau dieser Seite:
    http://www.webpagetest.org/result/120525_B0_E6G/

    Grüße
    Christian

  • Tim Lochmüller
    Tim Lochmüller (Autor) sagt:

    Einen passenden Time-To-First-Byte wert kann ich dir auch nicht liefern. Bestimmt kommt man besser als C weg, aber ich muss gestehen das ich das ganze Optimierungspotientail im letzten Jahr nicht mehr genutzt habe. Mann muss ja quasi stetig dran bleiben, weil ziemlich viele Änderungen (auch an Fremden Plugins ) gemacht werden, sodass alles perfekt in ein anderes passt. Wenn sich die Webseite immer weiterentwickelt (neue Plugins, alte raus), muss immer „nachoptimiert“ werden. Zudem muss ich gestehen das ich mich auf die Startseite konzentriert habe: http://www.webpagetest.org/result/120525_KW_HJB/1/pagespeed/

    Nach dem eigenen Test, werde ich die Problematik glaub ich nochmal aufgreifen müssen. Das sieht ja wirklich mies aus inzwischen… ;)

    Grüße,
    Tim

  • Ulrike Leugering
    Ulrike Leugering sagt:

    Hallo, hoffe ich finde hier Hilfe. Habe schon vier Firmen benutzt und alle haben nur Geld kassiert. Meine Seite ist einfach zu langsam. Eine zweite Seite von mir hat nun Fehlermeldungen, weil die NG Gallery nicht mehr will. Habe alle Bilder ausgewechselt und nun ist das Problem weg, aber Fehlermeldungen kommen. Bei dem Internetexplorer in einer Tour.
    Freue mich auf eine Antwort. Lieben Gruss Ulrike

  • Tim Lochmüller
    Tim Lochmüller (Autor) sagt:

    Hallo Ulrike. Das klingt ja nicht so gut… Die Maßnahmen, welche ich oben beschrieben haben, helfen auf den ersten Blick sehr gut. Es sollte jedoch nicht vergessen werden, das ggf. umfangreiche technische Fähigkeiten von Nöten sind (z.B. Datenbank Inizies setzen etc). Darüber hinaus, muss natürlich auch das Umfeld zur größe der Wesbeite passen… Dieser Blog läuft z.B. auf einem überdimensionierten Hosting-Paket, da es nur eine „kleine“ Seite neben ein paar größeren Projekten ist. Wenn deine Webseite eine gewissen Größe erreicht hat, ist zu empfehlen auch das Hosting demensprechend zu wählen. Wenn all das bereits geschehen ist und nicht geholfen hat, dann kannst du mir gerne eine Nachricht mit der Seite schicke und ich werfe mal einen Blick drauf… Grüße, Tim

Hinterlasse einen Kommentar/Leserbrief!

Füge deinen Kommentar hinzu oder sende einen Trackback von deiner Webseite aus.
Du kannst zudem die Kommentare via RSS abonnieren .

Sei freundlich! Halt dich ans Thema! Kein Spam!

Mit dem Absenden bestätigst du, dass es sich um keinen Spam handelt.