Das ganz normale Chaos, täglich frisch auf den Tisch. Direkt aus der hintersten Provinz in die Metropolen von Groß-Blogistan.


  1. Tempo, Tempo
  1. Tempo, Tempo

    Tue, 25 Mar 2008 17:11:03 GMT

    Bei Yahoo gibt es einen Artikel darüber, wie man Webseiten schneller macht. Wie ich aus eigener leidvoller Erfahrung bestätigen kann, sind auch heute, bei 6MBit/s und mehr, die "Geschwindigkeiten", mit denen viele Webseiten dargestellt werden, eher Langsamkeiten. Warum das so ist, erklärt dieser Artikel sehr schön, und bietet 14 Regeln für Webdesigner, wie Webseiten schneller gemacht werden können.
    Grundsätzlich stimme ich mit dem Inhalt dieses Artikels überein. Allerdings gibt es ein paar Kleinigkeiten zu bedenken. Ich persönlich bin ein Fan von Caches. Um Dateien im Cache zwischenspeichern zu können, muss die URL dazu bestimmten Bedingungen genügen (die Datei darf nicht dynamisch generiert werden), und wenn immer mögloch, sollte der Expires header gesetzt werden. Dies kann vom Websitebetreiber sehr einfach gemacht werden. Damit teilt man dem Browser mit, wie lange eine Datei gültig ist, d.h., wie lange es voraussichtlich dauert, bis sich diese Datei ändert. Für viele Bilder, die aus stilistischen Gründen, zur Dekoration, verwendet werden, kann man davon ausgehen, dass sich diese Bilder praktisch nie ändern. Da gerade diese Komponenten oft a) die größten und b) die meisten Komponenten sind, kann man hier am effektivsten eingreifen.
    Scripte ändern sich schon eher mal. Doch auch Scripte ändern sich nicht täglich. Nach einer gewissen Zeit der Konsolidierung, wenn eine Seite oder Site etabliert ist, ändern sich diese Scripte nur noch relativ selten. Einen vernünftigen Expires header zu setzen lohnt auch hier.
    Nun ist es so, dass die Forderung nach viel Inhalt in wenigen Dateien (zur Vermeidung unnötiger http requests) teilweise der Forderung nach guter Cachebarkeit entgegen läuft. Hier gilt es sorgfältig abzuwägen. Wenn man Alles in wenige (im Extremfall eine) Datei packt, verbessert man damit das Erlebnis für Erstbesucher. Das Erlebnis wird dann allerdings beim zweiten Besuch nicht besser. Setzt man eher auch Cache, hat der Erstbesucher keinen oder nur einen geringen Vorteil, das Erlebnis beim zweiten und allen folgenden Besuchen ist aber um so besser. Die optimale Vorgehensweise liegt also wohl offensichtlich in einem geeigneten Kompromiss.
    Ein drastischen und start verkürztes Beispiel: Angenommen, eine Seite X benutzt CSS styles, aber ausschließlich inline style. Dann muss dafür nur ein einziger http request abgesandt werden. Das ist vom Zeitaufwand her das geringst Mögliche. Legt man die Styles dagegen in einer externen css Datei ab, müssen zwei http requests gemacht werden, was die Responsezeit für den User deutlich erhöht. Allerdings wird die Datei dadurch deutlich größer. Die reine Übertragungszeit wird also relativ lang (wenn auch nicht länger als die reine Übertragungszeit für beide Einzeldokumente). Der Unterschied tritt nun zu Tage, wenn die zweite Seite geladen wird. Im Fall inline-style wird wieder ein http request gemacht und wieder eine lange Datei übertragen. Im Falle eines externen CSS Stylesheets wird stattdessen nur eine kurze html-Datei geladen, und das bereits geladene CSS Stylesheet wiederverwendet und aus dem Cache geholt. Das setzt natürlich voraus, dass das CSS Stylesheet auch das Selbe ist. Hier erlebt der User also bei der zweiten Seite einen immensen Geschwindigkeitszuwachs. Eine Geschwindigkeit, die in der inline-Version nie erreicht werden kann. Dafür ist diese Version der inline-Version beim ersten Besuch deutlich unterlegen. Hier einen geeigneten und vernünftigen Kompromiss zu finden bleibt dem Websitebetreiber und dem Webdesigner überlassen.
    Ein weiterer Punkt, der in diesen Regeln ansatzweise in der Regel Nummer 9 auftaucht, würde ich so umformulieren: Vermeide es, die Seite aus Komponenten zusammenzustellen, die von verschiedenen Servern kommen. Dies allerdings nicht nur, um die Anzahl der DNS Lookups zu verringern. Oft sind Server, deren Bilder, Logos oder Werbungen man direkt verlinkt, überlastet. Der Browser verbringt damit endlos lange Zeit, auf diese Kompone