Artikel
3 Kommentare

WordPress Performance – WPMeetUp September 2014

Gestern war WPMeetUp München, wir hatten uns das Thema „Performance“ vorgenommen. Da viele fitte Leute da waren, hatten wir eine lange, sehr spannende Diskussion. 

Zur Einstimmung hatte ich mir kurz vor dem Treffen unsere MeetUp-Seite hier bei Google PageSpeed angeschaut. Ich dachte mir: Kleine Seite, nix drauf, müsste eigentlich ganz flott sein. Denkste. Der Score lag bei traurigen 67/100. Das heisst, so ganz von selbst ist keine Webseite schnell. Man muss was dafür tun.

google

Für Eilige:
Wie es mit der WPMeetUp-Seite in Sachen Performance weitergegangen ist, könnt Ihr ganz unten am Ende des Artikels lesen.

Tools zum Messen der Performance

Um die Geschwindigkeit zu messen, ist Google Page Speed eine gute Adresse. Ein weiteres, sehr interessantes Tool ist auch WebPageTest. Das Schöne hier: Man bekommt sehr detaillierte Informationen über das Verhalten einzelner Elemente z.B. unter dem Tab „Performance Review“. Hier kann man zum Beispiel sehen, dass die Serververbindung immer wieder abbricht („Keep alive“) und dass so gut wie nichts gecacht wird („Cache static“). Wobei diese Angaben im Fall der Meetup-Seite nicht ganz konsistent sind (siehe unten).

cache

In der Waterfall-Darstellung sieht man, welche Vorgänge wie lange dauern, so ist zum Beispiel der Server nicht der Schnellste. Die Seite liegt auf einem einfachen Shared-Hosting-Paket, da ist die Reaktionszeit nicht so toll.

waterfall

Eine weitere Empfehlung kam von Hans Jung: rankwise.net. Damit kann man auch SEO-Gesichtspunkte prüfen und sehen, wie sich eine Seite im Umfeld der direkten Konkurrenten so schlägt. Das Tool ist nicht kostenlos, aber für Leute, die viele Webseiten prüfen müssen, ist rankwise eine Überlegung wert. Es bringt die Daten in aussagekräftige Zusammenhänge.

Faktoren für eine gute Performance

Es müssen ein paar Bedingungen erfüllt sein, damit die Inhalte schnell geladen werden. Wobei nicht nur die objektive Ladezeit, sondern auch das subjektive Empfinden eine Rolle spielt. So gibt es beispielsweise Dateien, die den Seitenaufbau „above the fold“ blockieren, also in dem Bereich der Webseite, der zuerst sichtbar ist. Häufig sind das Javascripts.

1. Asynchrones Laden von Javascripts

Das Laden von Javascripts auf einen späteren Zeitpunkt zu verschieben bringt eine bessere Performance. Der Browser muss dann mit der Darstellung der Inhalte nicht mehr warten, bis alle Scripte geladen sind. Das heisst: Der Besucher sieht keine leere Seite mehr.

Man kann auch CSS-Dateien asynchron laden, aber hier muss man aufpassen, dass die Seite danach noch richtig dargestellt wird. Im Zweifelsfall lieber ein paar Millisekunden Ladezeit in Kauf nehmen.

Auch das Zusammenfassen von mehreren Scripten zu einer Datei ist eine gute Methode, um die Ladezeit zu verkürzen. Aber nicht alle Javascripts mögen es, gebündelt zu werden. Hier hilft nur ausführliches Testen und Schauen, ob irgendwo wichtige Funktionen fehlen. Es kann sein, dass man für einzelne Javascripts, z.B. solche, die das Menü steuern, eine Ausnahme machen muss.

Im WordPress Plugin Directory gibt es eine ganze Reihe von Plugins, mit denen man Javascript und CSS bündeln und asynchron laden kann. Für mich hat Async JS and CSS ganz gut funktioniert, aber auch der Big Player unter den Performance Plugins, W3 Total Cache, bietet dazu viele Möglichkeiten.
Man muss allerdings wissen, dass W3 Total Cache nicht „out of the box“ funktioniert. Das Plugin will per Hand konfiguriert werden. Das macht auch Sinn, denn nicht jede Einstellung funktioniert für jede Webseite.

2. Inhalte speichern (Cache)

WordPress sucht sich bei jedem Browseraufruf alle Inhalte in Einzelteilen aus der Datenbank zusammen und erzeugt daraus den HTML-Code, mit dem der Browser die Seite darstellen kann. Na ja, theoretisch ist das so, in der Praxis speichern die Webbrowser Seiten, die man öfter besucht, in ihrem „Arbeitsspeicher“. Dann geht das Laden deutlich schneller.

Aber das Problem bleibt – ist eine Seite nicht im Browsercache, muss WordPress erst Mal basteln. Das ist unpraktisch, wenn man bedenkt, dass sich die Inhalte einer Seite gar nicht so oft verändern und x-Mal am Tag derselbe Inhalt abgerufen wird.
Deshalb macht es Sinn, die Inhalte schon in WordPress zu cachen, also zu speichern. Dann kann WordPress eine fertige Seite ausliefern.

Für diesen Zweck gibt es einige Plugins, zum Beispiel Cachify oder W3 Total Cache. Mit gecachten Inhalten lassen sich die Ladezeiten deutlich verkürzen.

3. Bilder komprimieren

Bilddaten können eine Webseite sehr wirksam ausbremsen. Das heißt, Bilder sollten so schlank wie möglich sein. Es gibt eine ganze Reihe von sehr leistungsfähigen Komprimierungstools, ich erwähne hier nur mal zwei Online-Tools: tinypng.org und jpegmini.com

4. Ein schneller Server

Wenn der Server zu lange braucht, um zu reagieren, dauert das Laden trotz Optimierungen noch ganz schön lange. Wer also wirklich Tempo haben will und eine gute Reaktionszeit braucht, kommt um einen schnelleren Server nicht herum und muss sich vom günstigen Shared-Hosting verabschieden. Leider kostet mehr Leistung auch mehr Geld.

5. Plugins unter die Lupe nehmen

Viele Plugins bedeuten zwar nicht zwangsläufig, dass eine Seite dadurch drastisch langsamer wird, aber man sollte natürlich nur die Plugins aktivieren, die man wirklich braucht. Und manche Plugins drücken mehr auf die Geschwindigkeit als andere. Mit dem Plugin Plugin Performance Profiler kann man sich anschauen, welche Plugins wie viel Ladezeit kosten.

Und wie kriegen wir jetzt die WPMeetup-Seite schneller?

Im Anschluss an unser Treffen hat sich Sven Hofmann die Seite geschnappt und eine Kopie auf seinen Server bei WPEngine gezogen. Und hat mal eben den Score von 69/100 auf 93/100 hochgedreht.

psi-stats
Seine Strategie:

  • CSS @import vermeiden
  • Ungenutzes CSS vermeiden
  • Ungenutzes JavaScript vermeiden
  • WordPress Meta vermeiden » Unhook
  • Bilder komprimieren
  • Scripts & CSS komprimieren
  • Nice to have: Scripts nachladen & Above the fold optimieren

Okay, dann schauen wir mal, ob ich das auch hinkriege.

Ich habe es mir leicht gemacht und W3 Total Cache installiert. Ganz so schick wie das von Sven ist mein Ergebnis nicht, aber der Unterschied ist deutlich:

google_vorhernachher

Abstriche musste ich beim CSS machen, da klappte das Zusammenfassen und/oder komprimieren nicht. Das Layout wurde falsch dargestellt. Das Theme ist ein Childtheme, die Styles vom Parenttheme werden per @import geladen. Mit etwas Geduld kann man das aber hinkriegen.
Außerdem kann mein Server mit WPEngine nicht wirklich mithalten.

Das Ergebnis auf webpagetest.org hat sich auch verbessert, wobei das Tool eisern behauptet, dass kein Cache am Werk ist. Und das „Keep Alive“ funktioniert angeblich auch nicht, obwohl in die htaccess Header set Connection keep-alive reingeschrieben habe.

UPDATE: Ich sehe gerade, Hans Jung hat über „Keep Alive“ geschrieben. Tja, der Code stimmt, aber bei mir tut er – angeblich – nichts. 😉

Beim nächsten Treffen im Oktober geht es um das Spannungsfeld „Designer und Entwickler“. Der Termin wird noch bekannt gegeben.

3 Kommentare

  1. Hallo Kirsten,

    vielen Dank fuer das Zusammenfassen. Gestern hatte ich die Funktion angesprochen, mit der man herausfindet, welche anderen Seiten auf dem Shared-Server liegen. Fälschlicherweise habe ich das Rankwise.net angedichtet – das kann dieses Tool aber nicht. Hiermit geht es:
    http://www.yougetsignal.com/tools/web-sites-on-web-server/
    Auf dem WPMeetUp Server liegen anscheinend 235 Seiten.

    Antworten

Schreibe einen Kommentar

Pflichtfelder sind mit * markiert.


In die Mailingliste eintragen (jederzeit wieder abbestellbar)