1&1 DSL - Performance-Optimierungen

1&1 DSL - Performance-Optimierungen

Das DSL-Projekt ging letzte Woche mit dem neuen Jasmin-Servlet 2.1 online. An diesem Beispiel möchte ich zeigen, wie eine weitere Optimierung dieses Projekts aussehen könnte.

Der erste Request

In der nachfolgenden Grafik sind sämtliche Requests in Form ihrer Bestandteile, Downloadzeiten und Latenzen beim ersten Aufruf der DSL-Startseite zu sehen. Die Latenzen werden dabei von der Software simuliert, stimmen aber in ihren Relationen zueinander.



Gleich die ersten Requests (1) wären Kandidaten für eine Optimierung. Das Pustefix-Framework macht ihr diverse Redirects, bevor es die eigentlichen Inhalte ausliefert. Ideal wäre natürlich wenn dies bereits mit dem ersten Request geschehen würde. Somit könnte die Zeit bis zum ersten Rendern der Seite (die grüne, vertikale Linie) deutlich verkürzt werden. Auch die mit (2) gekennzeichneten Requests beeinflussen den Zeitpunkt des ersten Renderns negativ. Diese Requests fordern die Stylesheets des Dokuments an. Die Platzierung der Requests ist optimal, je eher die Stylesheets geladen werden, desto besser. Allerdings ist die Größe der Daten ein Problem. Dies beeinflußt nicht nur die Downloadzeit sondern auch die Zeit der Interpretation der Stylesheets (3). Insgesamt dauert es in dieser Simulation mehr als eine Sekunde, diesen Prozess abzuschließen. Das ist immerhin 1/7 der Zeit, die der Browser mit der kompletten Darstellung des Dokuments beschäftigt ist. Zukünftig wird es dank des PMT möglich sein, diverse veraltete Selektoren aus den Stylesheets zu entfernen, was an dieser Stelle eine deutliche Verbesserung bringen sollte.

Im Anschluß an die Stylesheets werden die Grafiken der Startseite angefordert. Hier lassen sich für den ersten Request kaum Optimierungen finden. Eventuell sind einige weitere Hintergrundgrafiken Kandidaten für CSS-Sprites.

Interessant wird es wieder bei den JavaScript-Requests (4). Auch hier wird deutlich, dass der Umfang der Scripte recht groß ist, was wiederum zusätzlich zu einer Verzögerung bei der Interpretation des JavaScript-Codes (5) führt. Hier werden wir in Zukunft auf eine asynchrones Laden der Scripte mit einem Managed XHR setzen. Wem das nichts sagt, dem sei das Buch Even Faster Web Sites von Steve Souders empfohlen. Den Teil zum asynchronen Laden von JavaScript finde ich in diesem Buch neben den JavaScript-Code-Optimierungen am interessantesten.

Den Abschluß bilden jede Menge Tracking-Pixel-Requests. Diese stellen eine Besondere herausforderung dar, da sie nicht Teil der eigenen Infrastruktuer sind, sondern oftmals von fremden Servern, mit all den Nachteilen die so etwas hat, bezogen werden. Gerade heute morgen hatte ich eine Idee, wie wir dieses Problem mit einer zentralisierten Lösung für solche Requests in den Griff bekommen könnten - mal sehen, was mein Chef dazu meint

Der zweite Request

Dieser Request wird maßgeblich davon beeinflußt, dass der Browser bestimmte Daten bereits im Cache zwischengespeichert hat. Nur unter gewissen Umständen fordert dieser Daten erneut vom Server an.



Hier wirken sich die Redirects bis zur Auslieferung des HTML-Codes (1) in Relation noch massiver aus. Ein wesentlicher Teil der zeit bis zum ersten Rendern der Seite wird dafür beansprucht.

Ein viel größeres Problem wird durch die Bereiche (2), (3) und (4) sichtbar. Diese Bereich stellen sogeannte Conditional GET-Requests dar. Dabei wird beim Server erfragt, ob sich die bereits beim ersten Request abgerufenen Daten in der Zwischenzeit verändert haben. Bei den hier dargestellten Daten handelt es sich ausschließlich um Grafiken. Da sich das System, welches Grafiken zentral ausliefert und diese nur bei Veränderungen entsprechend neu versioniert, noch in der Planung befindet, müssen wir mit diesem Problem leider noch eine Weile leben. (Nachtrag: Der Content Delivery Server ist mittlerweile fertig implementiert.)

Als Fazit kann man sagen, dass wir mit unseren bisherigen Bemühungen schon große Schritte in Richtung eines performanten Frontends gegangen sind. Die hier beschriebenen Ansätze werden noch einmal eine deutliche Verbesserung bringen. Mit dem Ende dieser zweiten Phase wird das Thema Performance-Optimierung architektonisch abgehakt sein. Natürlich müssen wir während des Entwicklungsprozess bestehender und neuer Projekte darauf achten, Optimierungen am JavaScript-Code und an dem Umfang der ausgelieferten Ressourcen nicht aus dem Auge zu verlieren und als kontinuierlichen Teil unserer Arbeit zu sehen.

Die komplette Analyse ist bei webpagetest.org zu finden.

Geschrieben von Nico Steiner in Referenzen um 12:10 | Kommentare (0) | Trackbacks (0)

Kommentare

Ansicht der Kommentare: (Linear | Verschachtelt)

Noch keine Kommentare

Kommentar schreiben

Name
E-Mail
Homepage
Antwort zu	[ Ursprung ]
Kommentar	Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert. Um maschinelle und automatische Übertragung von Spamkommentaren zu verhindern, bitte die Zeichenfolge im dargestellten Bild in der Eingabemaske eintragen. Nur wenn die Zeichenfolge richtig eingegeben wurde, kann der Kommentar angenommen werden. Bitte beachten Sie, dass Ihr Browser Cookies unterstützen muss um dieses Verfahren anzuwenden. Hier die Zeichenfolge der Spamschutz-Grafik eintragen:
	Daten merken? Bei Aktualisierung dieser Kommentare benachrichtigen