Die SenSEO-Extension bekommt ein neues Feature "Analyze all pages". Hiermit soll es möglich sein, mit einem Klick die gesamte Website zu crawlen und sämtliche Seiten anhand vorgegebener Keywords zu bewerten. Dieses Crawlen und Bewerten wird ausschließlich mit Frontend-Technologien implementiert. Die nachfolgende Grafik zeigt die geplanten Schritte.



Der Anfang ist bereits geschafft. Mit diesem Prototypen (läuft nur im Firefox) ist es möglich, aus dem Markup einer vorgegebenen Seite sämtliche Links zu extrahieren. Es können lediglich Seiten von sensational-seo.com angegeben werden, da die Same Origin Policy nur Seiten der selben Domain für die Analyse zulässt.

Das Markup wird mit der XMLHttpRequest API abgerufen und mit der evaluate Function der Firefox XPath JavaScript API geparst.

Da die API lediglich DOM Dokumente https://developer.mozilla.org/en/DOM/document verarbeitet, wird die als String gelieferte XMLHttpRequest Response vorher einem iFrame als Inhalt zugewiesen. Der folgende Code macht dies möglich.

// create iframe

var responseTextIframeElement = document.createElement('iframe');

responseTextIframeElement.setAttribute('width', '0');

responseTextIframeElement.setAttribute('height', '0');

responseTextIframe = document.body.appendChild(responseTextIframeElement);

responseTextIframe.contentWindow.document.write(responseText);

var responseXML = responseTextIframe.contentWindow.document;

// clear iframe

responseTextIframe.parentNode.removeChild(responseTextIframe);

mse.Crawler.gotPageContentByUrl(responseXML);

Möchte man ohne XMLHttpRequest API arbeiten, kann man einem zuvor erzeugten iFrame auch einfach den URL als scr-Attribut zuweisen.

// create iframe

var responseTextIframeElement = document.createElement('iframe');

responseTextIframeElement.setAttribute('width', '0');

responseTextIframeElement.setAttribute('height', '0');

responseTextIframe = document.body.appendChild(responseTextIframeElement);

responseTextIframe.addEventListener('load', function(e) {

  var responseTextIframe = this;

  var responseXML = responseTextIframe.contentWindow.document;

  // clear iframe

  responseTextIframe.parentNode.removeChild(responseTextIframe);

  // this is not the best sollution

  mse.Crawler.gotPageContentByUrl(responseXML);

}, false);

responseTextIframe.src = url;        

Die Extrahierung der href-Attribute aus sämtlichen Anker-Tags übernimmt dann der folgende Code.

var allLinksXpath = responseXML.evaluate('/html/body//a/@href', responseXML, null, XPathResult.ANY_TYPE, null);

In einem nächsten Schritt sollen all die Verlinkungen extrahiert werden, welche absolut (mit http Schema) auf die selbe Domain verweisen oder Seiten relativ referenzieren. Diese Verlinkungen werden mit der Local Storage API auf einem Stack abgelegt und sequentiell nach dem LILO-Prinzip (Last in, Last out) gecrawlt. Dabei wird die Bereinigung von Dubletten mit Hilfe des Canonical-Tag eine wichtige Rolle spielen. Im Local Storage wird neben der extrahierten URL also auch immer eine zweite kanonische URL abgelegt, welche durch einen entsprechenden Abgleich das doppelte Crawlen von Seiten verhindern soll.

Bei Erkältung hilft nur eins - die Hühnersuppe ala Mama. Die Zubereitung ist einfach und der Erkältung fällt dann auch nix mehr ein.

Folgende Zutaten werden für eine große Portion Hühnersuppe benötigt (bei einer kleineren Portion die halbe Menge oder fertig abgepacktes Suppengemüse kaufen):

• 1 großes Suppenhuhn vom Markt oder aus dem BIO-Laden
• 250g Suppennudeln
• 1 Kohlrabi
• 1 Butterrübe
• 1 Knolle Sellerie
• 2 mittelgroße Möhren
• 1 Stange Lauch
• 1 Bund Petersilie
• Salz
• Gemahlener schwarzer Pfeffer

Das Huhn ggf. auftauen und dann mit viel Wasser und reichlich Salz in einem großen Topf bei halb aufgelegtem Deckel zum Kochen bringen. Danach auf mittlere Hitze zurückschalten und weiter kochen lassen.

Das Gemüse schälen und grob in größere Stücke zerteilen. Das Kleinschneiden kommt später. Beim Lauch gibt es zu beachten, dass auch die oberen, grünen Teile mitgekocht werden. Die Gemüsestücke zum Huhn in den Topf geben und ca. 20-30 Minuten gar kochen. Danach mit einer Schöpfkelle wieder aus dem Topf fischen (das Huhn kocht weiter), in eine Schüssel geben, klein schneiden und beiseite stellen. Je nach Geschmack nicht das gesamte Gemüse kleingeschneiden - von der Menge her ist das eher zu viel.

Wenn das Huhn nach 1-2 Stunden gar gekocht ist (das Fleisch sollte sich ganz leicht vom Knochen lösen lassen) aus dem Topf nehmen, die Haut und die Knochen entfernen und das Hühnerfleisch in kleine Stücke schneiden. Parallel dazu Wasser mit einer Prise Salz in einem separaten Topf zum Kochen bringen und die Suppennudeln darin nach Anleitung kochen. Die Nudeln danach in ein feinmaschiges Sieb abgießen und zusammen mit den Fleischstücken und dem geschnitten Gemüse zurück in den Topf geben.

Die Suppe mit Salz und Pfeffer abschmecken. Zum Schluss die Petersilie mit einem Wiegemesser klein schneiden und über die fertige Suppe streuen.

Ein paar Tipps

Suppe braucht viel Salz. Wenn trotzdem mal zu viel Salz an die Suppe gerät, hilft es, eine Kartoffel mitzukochen. Diese saugt das Salz auf und kann später weggeworfen werden.

Wer die Suppe nicht ganz so fett mag, kann sie auch erst erkalten lassen, dann in den Kühlschrank stellen und nach einigen Stunden die Schicht Fett abziehen, die sich auf der Suppe bildet.

Hühnersuppe läßt sich prima einfrieren. Größere Mengen am besten in Portionen aufteilen, da jedes erneute Aufkochen den Nudeln schadet.

Gestern erschien im Webstandard-Blog der erste von 3 Artikeln zur Verbesserung der Website-Performance mit Expires-Headern. Die Artikel basieren auf Steve Souders Veröffentlichungen und den praktischen Erfahrungen, die ich mit dem Content Delivery Server gesammelt habe. Der zweite und dritte Teil folgen die nächsten Tage.

Bin immer noch nicht zufrieden, gehe jetzt aber erstmal ins Bett.

Für die nächsten Stunden wird die Seite übel aussehen - danach hoffentlich nicht mehr...

Ich bin wieder zurück von der WebTechCon 2010. Neben einigen interessanten Vorträgen und jeder Menge Socializing habe auch ich einen Vortrag gehalten. Es ging um die Frontend-Architektur unserer Abteilung.

"Frontend-Architektur der 1&1 Bestellsysteme" bei Slideshare

Es gab einige interessante Fragen und jede Menge positives Feedback (zwitscher, zwitscher, zwitscher).

Einige Dinge, die ich aus den Gesprächen mitnehme:

• Viele Entwickler sitzen auf zwei Stühlen - PHP und das bißchen Frontend gleich noch mit. Den meisten ist bewußt, dass das alles andere als optimal ist
• Sehr gewachsene, heterogene Infrastrukturen - Konsolidierung nicht in Sicht (Zeit- oder Geldmangel)
• Uneinsichtige Chefs blockieren Innovationen
• Gute Kollegen trösten über vieles hinweg
• Kicker sind Mangelware
• Großraumbüros sind definitiv keine Option für Entwickler

Das macht mir mal wieder deutlich klar, wie gut wir eigentlich mit Personal und Systemen aufgestellt sind und wie viel Nachholbedarf andere Firmen da noch haben.

Letzte Woche war ich zusammen mit Andi und Mathias auf der Fronteers in Amsterdam. Chris Heilmann hat die Talks der Konferenz sehr gut zusammengefasst. Bleibt nur noch hinzuzufügen, dass der CSS3 Workshop von Dan Rubin sehr lehrreich und kurzweilig war.

Inspiriert durch dieses Meisterwerk von Jochen Malmsheimer (unbedingt vorher ansehen, sonst kommt der Witz nicht rüber) habe ich versucht, diesen Gag auf ein anderes Thema zu übertragen.

Die Webseite

Wie geht eine Webseite? Fangen wir unten an. Da ist das valides HTML. VALIDES HTML! Mit einer richtigen Semantik, damit die Elemente der Seite auch eine anständige Bedeutung haben. Richtiges HTML, semantisch, suchmaschinenoptimiert. Nicht diese zusammengeschusterte Tagsuppe, die ihr Layout in Tabellen presst und von Headlines noch nie etwas gehört hat!

Da drauf - extern, minimiert und komprimiert - gutes CSS! Man kann auch Stylesheets oder Layout dazu sagen. Und das CSS rendert von oben über das HTML, und dann lernen sie sich kennen und dann tun sie sich zusammen - denn sie wissen, gleich gibt's noch richtig was auf's Dach.

Und dann! Das ist jetzt ganz wichtig, Zettel raus, Stifte und mitschreiben - BITTE! Und dann...! Unobtrusive, buchstabiert U-N-O-B-T-R-U-S-I-V-E, JavaScript! Die Zeiten von Inline-Events sind vorbei!

Die müssen sauber voneinander getrennt sein! HTML und CSS bilden Gerüst und Layout der Seite und JavaScript fügt eine Logik-Schicht hinzu. Und dann gibt das eine Technologieexplosion, die einem die Zähne aus dem Hals bläst, wenn sie nicht ordentlich verschraubt sind!

DAS IST GUT! Seit Jahren ist das so gut! Das sind Webstandards!

Bis... zu diesem furchtbaren Tag... an dem so ein mental verotteter Grafiker (sorry, Jungs) DA FLASH DRAUFGEMACHT HAT, UND GRAFISCHE HEADLINES, UND VERLÄUFE UND OHNE ENDE SCHLAGSCHATTEN! DU HAST DAS GEFÜHL, DU BLICKST AUF EINE SCHIESSBUDE! DAS HAT DOCH MIT EINER WEBSEITE NICHTS ZU TUN! ICH WERDE NOCH WAHNSINNIG!

ICH... ich bin für den Einsatz des Militärs im eigenen Land! Die Soldaten sollen die Grafiker unter vorgehaltener Waffe dazu zwingen, ihre eigenen Webseiten mit einem Screenreader zu bedienen! Ein Grafiker soll morgens ins Büro kommen, eine anständige Webseite layouten und wieder nach Hause gehen - ist das denn so schwer ?!?

Das mache ich fast jeden Tag - könnt ihr euch das vorstellen? Das ich das gesundheitlich überhaupt mitmache! Auf der anderen Seite finde ich, dass ein so durchaus technologielastiges Blog wie dieses so einen Hauch von Emotion durchaus verträgt. Auf der anderen Seite fragt sich der eine oder andere Leser diese Artikels jetzt vielleicht... Was - hat - der - Mann?

RECHT HAT ER!!!

Danke an Andi und Matthias, die zum Teil unter dem Einsatz alkoholischer Getränke ihren Beitrag geleistet haben

Seit gestern werden auf der United Internet AG Website sämtliche Grafiken über einen Content Delivery Server ausgeliefert. Dieser komplettiert das Puzzle an Optimierungen, welches die Performance unserer Shops verbessern soll.

Folgende Features wurden in der ersten Phase implementiert:

- Far Future Expires Header (mehr Infos bei Yahoo!)
- Umschreiben der Grafikpfade auf eine Hashtag-Version
- Cookiefreie Domain (mehr Infos bei Yahoo!)
- Mehr parallele Downloads dank verschiedener Subdomains (mehr Infos bei Yahoo!)

Zum zweiten Feature habe ich keine gute Quelle im Netz gefunden. Es geht hierbei um das Problem, dass eine Grafik mit Expires Header ohne Conditional GET aus dem Cache geladen wird. Was prinzipiell erwünscht ist wird zu einem Problem, wenn eine veränderte Version dieser Grafik gepublished wird. Um dann trotzt des Expires Headers ein Neuladen zu erzwingen, ist eine veränderte Grafik-URL nötig. Für gewöhnlich kann man sich zwischen einer Versionierung und einem Hash Tag entscheiden. Letzteres erschien uns praktikabler, da ein Hash Tag vergleichsweise einfach implementiert werden kann. Facebook hat das gleiche Verfahren gewählt, Amazon dagegen setzt auf eine Versionierung der Dateinamen.

Eine Vorher-Nachher-Analyse belegt die Verbesserungen eindrucksvoll. Obwohl auf der Website vergleichsweise wenige Grafiken eingebunden werden, werden die Seiten beim 1. Request (dank 8 statt 2 parallelen Downloads) 25% schneller geladen. Beim 2. Request ist dank des optimalen Cache-Verhaltens eine Zeiteinsparung von fast 40% messbar. Es gibt diverse Studien, die eine verbesserte User Experience durch schnelle Ladezeiten belegen. Beispielhaft sei auf einige Statistiken der letzten Velocity verwiesen.

Im Verlauf der nächsten Monate werden wir den CDS in die sehr viel grafiklastigeren Shops integrieren und die Verbesserungen in diesem Umfeld dokumentieren. Man darf gespannt sein.

Für die Zukunft sind weitere Features geplant. So soll mit den Daten des CDS ein "selbstlernendes" Image Prefetching gebaut werden. In einem weiteren Schritt könnte der CDS zu einem Content Delivery Network ausgebaut werden, um statische Ressourcen weltweit mit möglichst geringer Latenz auszuliefern.

Darauf hoch die Tassen!

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.

Anhand eines unserer aktuellen Projekte möchte ich zeigen, wie die genannte Technologie in Hinblick auf die Performance einer Website zu verstehen ist.

Folgende Statistik habe ich mit der Firefox Extension YSlow erstellt. Oben ist die Verteilung der Ressourcen bei einem ersten Request mit leerem Cache zu sehen. Der Bereich darunter zeigt die Verteilung bei einem zweiten Request unter Ausnutzung des Caches.



Der obere Bereich zeigt die typischen Ressourcen einer Seite. Etwas ungewöhlich sind die 2 XML-HTTP-Requests. Dahinter verbergen sich JavaScripte, welche asynchron mit der Managed XHR Technik von Steve Souders in die Seite integriert werden.

Interessanter in Bezug auf die erwähnte Technologie ist der untere Bereich, nutzt man Expires Header doch, um das Caching-Verhalten einer Seite positiv zu beeinflussen. Hier ist zu sehen, dass Scripte und Stylesheets nicht mehr aufgeführt werden. Dies ist wenig verwunderlich, da wir diese bereits mit Far Future Expires Headern versehen haben.



Das Neuladen des HTML-Dokuments ist gewollt und wird mit einem in der Vergangenheit liegenden Expires Header erzwungen. Wir erzwingen für diesen Fall das Neuladen, da das Dokument dynamisch generiert wird und sich von einem Aufruf zum nächsten verändern kann.

Neben dem HTML-Dokument erzeugen sämtliche Grafiken der Seite erneut Requests. Bei diesen steht die Auslieferung eines Expires Header momentan noch aus. Was im ersten Moment nur nach einer Einstellung in den Apache-Konfigurationen klingt, wird auf den zweiten Blick sehr viel komplexer, möchte man durch eine möglichst transparente Versionierung der Grafiken ein Neuladen bei Veränderungen erzwingen. Zumindest ist durch korrekte ETags sichergestellt, dass lediglich Requests in Form eines Conditional GET gemacht werden - die Daten selbst werden also nicht erneut übertragen. Allerdings braucht solch ein Request für den gesamten Roundtrip auch etwas Zeit - bei 40 Requests macht das in einem modernen Browser wie dem Firefox immer noch ganze 2 Sekunden aus!

Nachtrag: Die Grafiken werden mittlerweile mit Hilfe des Content Delivery Server mit Expires Header ausgeliefert.

Ich werde am 9. November auf dem PHP World Kongress einen Vortrag zur Verbesserung der Website Performance halten.

Abstract
Wie verbessere ich die Ladezeiten meiner Websites und welche Vorteile ergeben sich daraus? Auf der Basis allgemeingültiger Regeln werden in diesem Vortrag Lösungen vorgestellt, wie sie im Umfeld der 1&1 Shopsysteme entstanden sind. Es wird weiterhin erläutert, wie zentralisierte Technologien dafür sorgen können, dass diese Optimierungen projektübergreifend angewendet werden, Kennzahlen erhoben und mögliche Schwachstellen identifiziert werden können.