In einem vorhergehenden Beitrag habe ich mich mit der Auswahl von Performance Test Tools befasst (siehe [intlink id=”1796″ type=”post”]Performance Tests für Websites und Shops[/intlink]). Eines der dort vorgestellten Tools war webpagetest, das unter webpagetest.org als Service nutzbar ist. Dieser Beitrag ist der Versuch tiefer in die Details des Service einzusteigen.

Für mein Vorgehen werde ich mich am Vorgehen nach der Form Plan-Do-Check-Act, dem sogenannten Demingkreis orientieren.

Phase	Vorgehen
Plan	Der Test ist in der Durchführung natürlich durch die zweifache Messung des Werkzeugs schon vorgegeben. Meine Planung sieht aber zusätzlich zwei Tests vor. Der zugrundeliegende WordPress Blog nutze ein Caching Plugin (WP Super Cache). Meine Idee ist es den ersten Test ohne Cache, den zweiten mit eingeschaltetem Cache durchzuführen.Der Ort der simulierten Abfrage ist Deutschland, da hier die meisten meiner Besucher herkommen, als Browser nehmen ich einheitlich Firefox.
Do	Der Test wird durchgeführt.
Check	Ich werde im Check versuchen die größten drei Performancefresser zu identifizieren. Weitere kommen dann erst im zweiten Durchlauf nach der Optimierung.Da ich vorhabe, diesen Test mit mehreren Performance Werkzeugen durchzuführen, möchte ich vor dem Act noch den Vergleich der Ergenisse stellen. Die Frage die mich interesseiert ist natürlich, ob die Ergebnisse übereinstimmen.
Act	Ich werde versuchen die größten performancekiller zu beseitigen um dann in einen neuen Durchlauf zu gehen. Wird im ersten Schritt hier auch nicht beschrieben.

Do – Durchführen der Messung

Das Vorgehen zur Testdurchführung ist wie folgt:

1. Cache Deaktivieren
2. Messung ohne Cache durchführen
3. Cache Aktivieren
4. Startseite im Browser öffnen um sicherzustellen, dass der Cache greift
5. Messung mit Cache durchführen

Check – Bewertung der Messung

Hier gibt es den erste Aha-Effekt. Die Messung mit und ohne Cache unterscheidet sich nicht. Was zwei Interpretationen zuläßt:

• Bei der Messung ohne Cache war der Cache noch aktiv
• Bei der Messung mit Cache hat der Cache nicht gegriffen

Der Cache zeigte nach der zweiten Messung Inhalte an (Filesystem) und wies dabei auch die getestete Seite aus. Durch leeren des Cache habe ich sichergestellt, dass der Cache keine Inhalte liefern kann und die Messung ohne Cache in leicht modifizierter Form als Messung mit leerem Cache wieder durchgeführt und siehe da, die Ladezeiten waren höher.

	Messung mit leerem Cache					Document Complete			Fully Loaded
	Load Time	First Byte	Start Render	Speed Index	DOM Elements	Time	Requests	Bytes In	Time	Requests	Bytes In
First View	10.293s	1.083s	2.333s	2394	867	10.293s	61	5,010 KB	11.512s	62	5,013 KB
Repeat View	2.553s	0.204s	1.011s	1066	867	2.553s	48	155 KB	3.445s	48	158 KB

	Messung mit Cache					Document Complete			Fully Loaded
	Load Time	First Byte	Start Render	Speed Index	DOM Elements	Time	Requests	Bytes In	Time	Requests	Bytes In
First View	9.508s	0.210s	1.531s	1695	867	9.508s	61	5,010 KB	10.766s	62	5,013 KB
Repeat View	5.159s	0.972s	0.833s	879	867	5.159s	47	136 KB	5.197s	47	136 KB

Überraschend für mich war der hierbei doch recht geringe Unterschied von 0,7s. Der Cache hat also einen messbaren Effekt, aber nicht in der von mir eigentlich erwarteten Größenordnung (< 50%).

Der Cache Blick in die Details

Um den Effekt des Cache zu erfassen sollte ein Blick auf den ersten HTTP Request ausreichen. Der Aufruf der eigentlichen Seite sollte wahlweise aus dem Cache beantwortet werden oder zu einem Rendering der Seite mit anschließendem Caching führen.

Für das bessere Verständnis der nachfolgenden Chart, zuerst einmal die Bedeutung der Farben.

Im ersten Chart sehen wir die ersten Ladezeiten der Hauptseite. Auffällig ist die Dauer von ca. einer Sekunde, bis der erste Request mit dem ersten Byte (Zeile 1, grün) beantwortet wird. Dies ist die Zeit, die für das Rendering der Seite benötigt wird.

Entsprechend ist die Antwortzeit beim ersten Request auf ein Minimum zurückgefallen, sobald der Cache aktiv ist. Damit ist die Funktion des Cache gezeigt, aber noch keine Optimierungspotential geschaffen. Die Durchsicht des nachfolgenden “Waterfall View” zeigt auch, dass sich die Ladezeiten mit – und ohne Cache nicht mehr unterscheiden.

Daraus ergibt sich für die weitere Bewertung, dass ich diese nur noch mit einer Messung fortsetzen werde. In diesem Fall die Messung mit Cache.

Der Cache Blick in die Details

Ein Blick auf das zweite Standarddiagramm, den Connection View, weißt die Blickrichtung bei der Optimierung.

Die langen Balken in lila (=images) deuten auf Probleme bei den Bildern hin. Insbesondere in Zeile 14, ein Bild, das von einer fremden Quelle eingebunden ist, dominiert die Geschwindigkeit negativ. Allerdings sind weitere Bilder ebenfalls sehr langsam. Weiter fällt ein CSS (grün) in Zeile 5 ins Auge, das mit mehr als einer Sekunde zu Buche schlägt.

Das original Chart bietet einen praktischen Rollover, der hier die Verursacher offenbart.

Auf diesem Weg sind die entsprechenden Requests zu identifizieren und im Wasserfall zu finden. In der Wasserfallansicht finden sich diese Positionen wieder. In der nachfolgenden Ansicht sind diese rot marktiert und mit Nummern versehen.

1. Das Custom-CSS wird abgefragt. Der grüne Balken zeigt an, dass WordPress hier relativ lange rechnet bis dieses bereitgestellt ist (0,7 Sekunden). Eine Optimierung muß demnach die Verarbeitung in WordPress verkürzen.
2. Ein Bild von einer fremden Quelle braucht zu lange um geladen zu werden. Es ist damit entweder zu groß oder die Quelle zu langsam. Hier scheint es sinnvoll das Bild lokal abzulegen und zu verkleinern.
3. Mehrere lokale Bilder mit hohen Ladezeiten. Die Bilder sind zu groß.
4. Linked In Einbindung wird langsam ausgeliefert – der LinkedIn Server antworte langsam.
5. Die Twitter API reagiert zu langsam.

Dies wird im großen und ganzen auch von der Schulnotenbewertung des Service gestützt. Es wird hier aber zusätzlich noch die Verwendung von “Progressive JPG” eingefordert.

Ich würde damit die Liste der Maßnahmen folgendermaßden definieren:

1. Fremdes Bild lokal ablegen und in ein reduziertes Format bringen, eventuell verkleinert einbinden und Original verlinken. Progressive JPG nutzen.
2. Lokale BIlder – verkleinern und Progressive JPG
3. Custom CSS – eventuell abschalten und Änderungen direkt im WordPress Theme umsetzen
4. Die Twitter und LinkedIn Aufrufe könnten eventuell entfernt werden – kein Share mehr möglich.

Mehr zum Vergnügen denn als ernsthafte Anwendung, hier ein Video von meinem Blog beim laden

 Nachtrag: Act (28.01.2014)

Die erste Änderung habe ich vollzogen. Sie entspricht zwar noch nicht ganz den Maßnahmen die ich geplant habe, ist aber ein guter erster Schritt. Um die Ladezeit meines blogs zu optimieren, habe ich bei älteren Artikeln konsequent die “Weiterlesen” Funktion genutzt. Damit fallen die kritischen Bilder von der Startseite weg.

Das nachfolgende (nicht optimal performanceoptimierte) Bild zeigt, dass dies schon eine Verbesserung um 6 Sekunden für den ersten Load gebracht hat.