Performance Analyse - Teil 3
Diesmal sollen die Ladezeiten, der Zeitpunkt des Rendering-Starts, die Anzahl der Requests und das Seitengewicht (in den Diagrammen für eine bessere Darstellung auf ein Zehntel reduziert) gegenübergestellt und verglichen werden. Unterschieden wird dabei zwischen dem ersten Request ohne gecachte Daten und dem zweiten Request, bei dem der Browser unter Umständen Daten aus dem ersten Request gecacht hat.
Erster Request (ohne gecachte Daten)
Daten in Tabellenform
Zweiter Request (mit gecachten Daten)
Daten in Tabellenform
Auffällig ist dabei, wie schnell die T-Home-Webseite trotz ihrer beachtlichen Größe im Vergleich zu den anderen Webseiten geladen wird.
Weiterhin fällt auf, daß das Seiten-Rendering bei der 1&1-Seite verhältnismäßig spät startet. Dies wird im Wesentlichen dadurch verursacht, daß das JavaScript noch im Head geladen wird und somit ein progressives Rendering der Seite verhindert wird. Die eigentliche Ladezeit vergrößert sich dadurch zwar nicht, nur ist die erlebte Wartezeit für den Kunden um einiges länger als bei den Seiten mit besserem progressiven Rendering.
Bei einigen der Seiten nimmt die Anzahl der Requests beim zweiten Request kaum ab, was ein Hinweis auf fehlende Expires-Header sein dürfte. Fehlen diese Header, werden Conditional-Get-Requests ausgeführt, welche die Daten im Cache auf Aktualität prüfen. Als weitere Ursache könnten die in Steve Souders Buch beschriebenen Probleme mit eTags in Cluster-Systemen in Frage kommen.
Archive
- Februar 2012 (1)
- Oktober 2011 (1)
- August 2011 (2)
- April 2011 (1)
- Oktober 2010 (6)
- September 2010 (5)
- August 2010 (3)
- Juli 2010 (2)
- Juni 2010 (3)
- Mai 2010 (9)
- April 2010 (8)
- März 2010 (13)
- Februar 2010 (10)
- Januar 2010 (11)
- Dezember 2009 (8)
- November 2009 (6)
- Oktober 2009 (10)
- September 2009 (9)
- August 2009 (12)
- Juli 2009 (16)
- Das Neueste ...
- Älteres ...
Trackbacks