Nico Steiner - Frontend-Entwicklung und -Architektur

Sonntag, 18. Oktober 2009

SenSEO 1.0 veröffentlicht

Am 21. Oktober 2008 habe ich die Firefox-Extension SenSEO veröffentlicht. Nach einem Jahr Entwicklungzeit ist seit ein paar Minuten Version 1.0 von SenSEO bei den Mozilla Add-Ons (vorerst) experimentell verfügbar.
In dieser Version kamen keine neuen Features hinzu. Statt dessen gibt es am Ende der SenSEO-Analyse einen Hinweis auf die Möglichkeit einer PayPal-Spende. Jetzt kann der Rubel rollen

Geschrieben von Nico Steiner in Referenzen um 18:23 | Kommentare (0) | Trackbacks (0)

Ansätze für den Umgang mit Tracking-Pixeln

Ein Tracking-Pixel ist ein für gewöhnlich 1x1 Pixel großes Gif, welches von einem Server mit Hilfe eines IMG-Tags abgerufen wird. Interessant ist dabei, dass mit dem Request Tracking-Daten übermittelt werden, welche auf dem Pixel-Server geloggt werden. Die Grafik ist dabei nur eine Krücke, da in den Anfängen dieser Idee eine Technik wie AJAX zur Übermittlung von Daten aus einer Seite heraus noch nicht bekannt war und diese Lösung auch ohne JavaScript implementiert werden konnte.

Doch Tracking-Pixel haben ihre Nachteile. Zum einen tendiert diese Technik zum Ausufern. Sind viele Systeme an einer Website beteiligt, bringen diese oft auch eigene Implementierungen solcher Pixel mit. Denn einen Standard für Tracking-Pixel gibt es nicht. Noch dazu werden Tracking-Pixel fast immer von Servern mit eigenen Domains abgerufen, was zu einer Häufung von DNS Lookups führt. Nicht zuletzt integrieren sich diese Server mit ihrem Response-Verhalten in das eigene Frontend - geraten sie unter zu große Last oder fallen sie gar ganz aus, hat das direkten Einfluß auf die eigenen Seiten.

Um diese Probleme in den Griff zu bekommen, gäbe es zwei Ansätze.

Der erste, relativ einfach zu implementierende Ansatz, wäre eine Umstellung der Requests von einem IMG-Tag auf einen asynchronen AJAX-Call. Dies hätte den Vorteil, dass das Response-Verhalten fremder Server sehr viel weniger kritisch wäre. Die Daten würden asynchron außerhalb des Kontext des eigentlichen Ladens und Renderns der Seite abgerufen. Dabei sollte es egal sein, ob das zurückgelieferte Pixel tatsächlich in die Seite eingebettet wird - es zählt ja einzig der Request. Eventuelle Verzögerungen oder Server-Ausfälle würden keinen direkten Einfluß mehr auf die eigene Website haben. Leider muß man bei dieser Lösung im Frontend immer noch auf die unterschiedlichen Implementierungen der Anbieter Rücksicht nehmen.

Um zumindest im Frontend von den unterschiedlichen Implementierungen der Tracking-Pixel-Anbieter wegzukommen, gäbe es einen zweiten Ansatz. Man würde einem auf dem eigenen Server befindlichen Script alle nötigen Daten mit genau einem Tracking-Request übergeben. Das Script würde diese Daten dann auf die unterschiedlichen Tracking-Pixel-Requests mappen, und die Grafiken dann direkt vom Server aus abrufen. Die Logik zur Behandlung unterschiedlicher Pixel würde also komplett von einem Tracking-Script übernommen werden. Damit wären zumindest aus Frontend-Sicht alle Probleme gelöst.

Geschrieben von Nico Steiner in Referenzen um 14:00 | Kommentare (2) | Trackbacks (0)

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)