Performance Test mit Webpagetest.org

WebPagetest Logo - Website Performance and Optimization TestIn 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.

Abfrage www.online-targeting.com bei leerem Cache

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.

Abfrage www.online-targeting.com bei aktivem Cache

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.

www.online-targeting.com - connection view- coloured by MIME

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.

www.online-targeting.com - waterfall - Problemstellen markiert

  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.

WebpageTest.org - Schulnotenbewertung meines Blogs  - AAAFFF

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.

WebPagetest Test Result - Falkenstein  www.online-targeting.com - nach Änderung

 

 

Kommentar verfassen