Bewertung von Messergebnissen und Routine Checks

Bevor mit ein­er Opti­mierung der Per­for­mance begonnen wird, soll­ten die Ladezeit­en und die damit ver­bun­de­nen Opti­mierungspo­ten­tiale ermit­telt wer­den. In dem weit­eren Ver­lauf ist es empfehlenswert die Per­for­mance fort­laufend zu überwachen, um Abwe­ichun­gen frühzeit­ig zu erken­nen und beheben zu kön­nen. Dazu bietet sich eine Kom­bi­na­tion ver­schieden­er Werkzeuge an, die eine ein­fache Bew­er­tung der Web­seite anhand von Bew­er­tungssys­te­men vornehmen [Ber15].

Die Entwick­ler-Tools in Browsern vergeben keine Bew­er­tun­gen und ermöglichen somit keinen ein­fachen Ver­gle­ich ver­schieden­er Web­seit­en, weil die Ergeb­nisse von den Entwick­lern jew­eils gele­sen und entsprechend inter­pretiert wer­den müssen. Mit den Bew­er­tun­gen von YSLOW, Page­Speed Insights oder dem Speed Index von Web­Pagetest hinge­gen lassen sich die Web­seit­en durch die erziel­ten Punk­te ver­gle­ichen. Offen­sichtliche Opti­mierungspo­ten­tiale kön­nen auf diese Weise direkt aus den Hand­lungsempfehlun­gen ent­nom­men wer­den. Wasser­fall­dia­gramme zur Analyse und Auswer­tung wer­den jedoch wed­er von YSLOW, noch von Page­Speed Insights erstellt. Web­Pagetest ermöglicht umfassende Ver­gle­iche zwis­chen mehreren Web­seit­en und bere­it­et die Messergeb­nisse in ver­schiede­nen Dia­gram­men über­sichtlich auf.

Bei der Analyse von Wasser­fall­dia­gram­men ist auf Abwe­ichun­gen der Erre­ich­barkeit der Web­seit­en zu acht­en, da es durch eine unter­schiedlich starke Aus­las­tung der Net­ze und die Wahl der Rout­ing­wege zu Verzögerun­gen beim DNS-Lock­up sowie der Time to First Byte kom­men kann. Sind in den Ergeb­nis­sen Abwe­ichun­gen ersichtlich, ist ein erneuter Test durchzuführen, um die Ver­gle­ich­barkeit der Mess­werte sicherzustellen.

Abbil­dung 2.18: Abruf ein­er Web­seite von den Stan­dorten Frank­furt (DE) und Ams­ter­dam (NL)

Bei den Ver­suchen im Zuge dieser Arbeit zeigte sich, dass der Zeit­punkt und die Wahl des Test­stan­dortes Auswirkun­gen auf die ermit­tel­ten Messergeb­nisse haben kön­nen. Abends durchge­führte Ver­suche erziel­ten zum Teil bessere Ergeb­nisse als Ver­suche am Vor­mit­tag. In der Abbil­dung 2.18 wird ein Unter­schied der Ladezeit von 0,3 Sekun­den zwis­chen den Stan­dorten Frank­furt und Ams­ter­dam während des unmit­tel­baren Abrufs der gle­ichen Web­seite gezeigt. Aus diesem Grund ist es empfehlenswert vor der Durch­führung von Ver­gle­ich­stests zu prüfen, welch­er Server­stan­dort die bessere Verbindung zum Web­serv­er erre­icht und die Test­durch­läufe unmit­tel­bar nacheinan­der auszuführen.

Bei der Per­for­manceop­ti­mierung ist nicht nur die erforder­liche Ladezeit und der Umfang des Daten­vol­u­mens zu beacht­en, son­dern auch die vom Nutzer wahrgenommene Ladezeit. Die Darstel­lung des sicht­baren Bere­ich­es (Visu­al­ly Com­plete) ste­ht jedoch nicht zwin­gend in einem Zusam­men­hang mit dem Umfang des Daten­vol­u­mens. Scott Jehl schreibt dazu: „Weight doesn’t nece­sar­i­ly need to increase the time a user needs to wait to use a page“ [Jeh14a]. Aus Sicht der User Expe­ri­ence sollte auf die Zeit geachtet wer­den, die erforder­lich ist, um eine Web­seite bedi­en­bar zu machen [Ber15]. Dieser Fak­tor wird auch zur Bil­dung des Speed Index von Web­Pagetest herange­zo­gen.

Entwick­ler-Tools und YSLOW soll­ten laut Lara Hogan bere­its während der Entwick­lung genutzt wer­den. Nach der Fer­tig­stel­lung der Web­site emp­fiehlt sie, ein­mal pro Quar­tal die erziel­ten Werte einzel­ner Seit­en zu über­prüfen. Nach umfassenden Änderun­gen soll­ten zusät­zlich syn­thetis­che Tools genutzt wer­den und im Rah­men des Real User Mon­i­tor­ing eine wöchentliche Auswer­tung erfol­gen, um die durch­schnit­tliche Ladezeit und die demografis­che Aus­rich­tung der Nutzer zu analysieren [Hog15].

Beim Real User Mon­i­tor­ing ist zu hin­ter­fra­gen, auf welch­er Basis die Dat­en erhoben wur­den. Ist die Grund­menge der Nutzer zu ger­ing, lassen sich keine aus­sagekräfti­gen Ergeb­nisse erzie­len. In diesem Fall ist eine Anpas­sung der Sam­pler­ate (siehe Kapi­tel 2.2.3) zu empfehlen. Die Nutzung von Google Ana­lyt­ics hat zum Nachteil, dass sich damit nur Durch­schnittswerte ermit­teln lassen und Aus­reißer keine Beach­tung find­en [Ste12].

Sofern viele Per­so­n­en an ein­er Web­site mitar­beit­en emp­fiehlt es sich, in regelmäßi­gen Abstän­den Rou­tine Checks vorzunehmen, um Änderun­gen, die neg­a­tive Auswirkun­gen auf die Per­for­mance haben, frühzeit­ig zu iden­ti­fizieren. Dies kön­nen beispiel­sweise zu große oder falsch kom­prim­ierte Bilder sein. Es ist daher von Vorteil bere­its während der Pla­nung ein Per­for­mance Bud­get (nach­fol­gend in Kapi­tel 2.3 behan­delt) zu definieren und dessen Ein­hal­tung zu prüfen [Hog15]. Die Messergeb­nisse lassen sich bei vie­len Tools als HAR-Datei spe­ich­ern, dabei han­delt es sich um eine HTTP-Archive-Datei, in der Infor­ma­tio­nen zu den HTTP-Anfra­gen, den über­tra­ge­nen Inhal­ten und die Über­tra-gungs­dauer enthal­ten sind [KR13]. Mit dieser Datei kön­nen Ergeb­nisse archiviert und mit Tools wie dem HAR Ana­lyz­er von Google analysiert und ver­glichen wer­den.