In meiner Blog Reihe zur Optimierung der Pagespeed möcht ich heute auf das verwenden von “distinct Hosts” eingehen.

Einleitung

Ein Webbrowser ist in der Regel limitiert eine Maximale Anzahl an Verbindungen pro Host aufzubauen. Bei optimierten Browsern wie Opera oder Firefox ist diese Anzahl bereits relativ hoch bzw. teilweise Dynamisch. Bei älteren Browsern dagegen ist hier oftmals ein Limit auf 4 oder 8 Verbindungen pro Host fest gesetzt. Nun, eine Webseite besteht nicht selten aus hunderten Elementen; jede Grafik, jedes JavaScript jeder Ajax Request ist ein “hit” jeder Hit wiederum verlangt in der Client – Server Kommunikation einen kompletten Handshake.
Eine Typische HTTP Kommunikation ist in Abb 1 zu sehen, grün ist der “Request” vom Webbrowser (client) an den Server und rot ist die vom Server entgegnete Antwort. Wenn man nun annimmt eine Beispiel-Webseite bestünde aus 70 einzelnen Elementen, so wäre dies 70x das selbe Client-Server “geschwätz” was schon einiges an “Kommunikationsaufwand” bedeutet.In der Realen Welt ist es nicht ungewöhnlich das duzende kleinst Grafiken geladen werden. Mal ein Beispiel an einer einfachen Flagge wie ich sie öfters auf der Seite verwende Dieses de.png ist 129 Bytes klein, allein die nötige Client – Server Kommunikation für diese Flagge umfasst allerdings bereits 1.822 Bytes; Das ist 14x mehr als die Größe der eigentliche Datei selbst.Vor der eigentlichen Header Übertragung kommen nun noch die üblichen Verzögerungen durch das TCP Protokoll hinzu. Um den Beitrag nicht zu sprengen nur kurz hierzu:
  1. Anfrage http://host.name/de.png
  2. Namensauflösung host.name
  3. Verbindung auf IP Port 80
  4. TCP Handshake
  5. Anfrage Client –> Server (Abb1 grün)
  6. Antwort Server –> Client (Abb1 rot) vorbereiten des Clients auf Datenempfang
  7. Eigentlicher Datentransfer Server –> Client
  8. Bestätigung
  9. Verbindung trennen
Diese Prozedur bei jeder noch so kleinen Grafik kostet eben Zeit. Die meisten Browser oder auch das Betriebsystem greifen hier schon unter die Arme in dem z.B. DNS Caches verwendet werden.

Keep-Alive

Um das ganze nun weiter zu optimieren unterstützen alle modernen Webbrowser so genannte Keep-Alive requests. Diese halten nach Schritt 8 die Verbindung für eine bestimmte Zeitspanne offen und warten sozusagen, auf der selben Leitung, auf weitere Anfragen des Webbrowsers. Somit beschränkt sich die Kommunikation auf das Schema: 1,2,3,4, (5,6,7,8), (5,6,7,8), (5,6,7,8),[…] 9Da dies für den Webserver aber auch bedeutet Ressourcen an Clients zu “reservieren” ist man als Webmaster hier meist sehr restriktiv. Länge und mehr Keep-Alive Möglichkeiten erhöhen die Gefahr bei viel Ansturm nicht mehr erreichbar für “neue” Clients zu sein. Zudem steigt die Anfälligkeit für einfache DoS Attacken (Denial of Service). In der Antwort des Servers erkennt man in Abb1 die Konfiguration der Keep-Alives in Form von: Keep-Alive: timeout=6,max=32 Der Webserver teilt hier dem Browser mit das er die Verbindung 6 Sekunden offen halten kann und maximal 32 Anfragen pro Verbindung akzeptiert.

Distinct Hosts / Static Domains

Auch wenn die Kommunikation nun auf Schritt 5-8 beschränkt ist bedeutet das noch nicht das wir die am Anfang der Einleitung angesprochenen Header los sind. In unserem Beispiel “de.png” war der Header ja 14x größer als die eigentlichen Daten. Wie man in Abb1 erkennt beinhalten die HTTP Header viele Informationen die ein statischer Content wie ein PNG niemals brauchen wird. So z.B. Cookies, Etags oder andere erweiterte Cache Informationen. Bleiben wir aber mal bei den Cookies, fast jede Webseite nutzt heutzutage Cookies. Ob für Sessions, zur Identifizierung des Nutzers oder für Analytics. Diese Cookies werden bei jedem Request vom Webbrowser alle an den Webserver geschickt damit dieser, bei Bedarf, diese Informationen auswerten kann. Hier sind wir nun an dem Punkt an dem deutlich wird was ich meine; Wozu braucht ein de.PNG alle meine ? In 99% der Fälle eben gar nicht.
Nun kommen die so genannten “Distinct Hosts” oder “Static Domains” ins Spiel. Neben der eigentlichen Domain der Webseite kommen nun noch eine weitere Subdomain ins Spiel. Statische Inhalte wie Grafiken oder sich nicht ändernde JS Daten werden nun nicht mehr von http://www.solariz.de/gfx/ geladen sondern von einer neuen Subdomain: http://static.solariz.de/ diese beinhaltet eigentlich 1:1 das selbe wie der vorherige GFX Ordner. Allerdings wird der Webserver hier auf die Auslieferung von statischem Content optimiert. Bei großen Projekten ist es sinnvoll hier einen weiteren Webserver zu verwenden der sich nur um die Auslieferung des statischen Inhalts zu kümmern hat. Damit ist die “Last” des Traffics hierfür vom Hauptwebserver genommen. In Abb2 sieht man eine Client – Server Kommunikation mit einer optimierten statischen Domain. Diese ist für genau den selben Sinn und Zweck um gut 1KB geschrumpft. Bei unserer Beispiel-Webseite mit 70 Elementen wären dies auch rund 70KB weniger die bei jedem Seitenaufruf transferiert werden müssen.Oftmals wird für Static Hosts eine sehr abgespeckte Version des Apaches mit minimaler Anzahl an Modulen genutzt. Kein PHP, kein CGI, kein Auth, keine Etag Berechnung. Alles wird auf das nötigste runtergefahren. Somit ist die Kommunikation zwischen Client und Server in der Regel auch schneller.Doch das waren nicht alle Vorteile, durch die Verwendung einer Subdomains bleiben auch die Cookies außen vor da diese auf der Hauptdomain liegen. Zudem hat der Webbrowser nun die Keep-Alive Range des normalen Hosts für reine HTML Anfragen was die Pageload Zeit beschleunigt.Zu guter letzt sei noch zu erwähnen das zeitgleich somit 2x soviel Verbindungen aufgebaut werden könnten und das Laden von mehreren Hosts somit Parallel erfolgen kann.

Amazon Logo Diesen Blog unterstützen?
Bestell dir doch etwas bei Amazon. Nutze diesen speziellen Link, es kostet dich nichts extra und für jeden Kauf darüber erhalte ich eine kleine Gutschrift. Danke!
✉ Marco Götze//

Kommentare

Formate: | Größe: Mb
Anmelden mitoder Benutzernamen eingeben

solariz
@Peter: Kannte ich schon, nützliche Sammlung. Ich finde allerdings einige Tips sind kaum bis garnicht umzusetzen man muss immer den Mittelweg zwischen Seitenoptimierung und usability nehmen. Gerade mit den Sprites ist das so ne sache. Was packt man rein in die Sprites was lässt man als einzelgrafik. Viele dinge werden ja extern zugeladen und machen da die eigentlichen Probleme. Beispiel Affiliate oder Network Buttons. Denn da nutzt die beste Seite die in unter 2s läd nichts wenn die Networkbuttons 6-7s brauchen ;|
★Marco Gö†ze
@Peter: Kannte ich schon, nützliche Sammlung. Ich finde allerdings einige Tips sind kaum bis garnicht umzusetzen man muss immer den Mittelweg zwischen Seitenoptimierung und usability nehmen. Gerade mit den Sprites ist das so ne sache. Was packt man rein in die Sprites was lässt man als einzelgrafik. Viele dinge werden ja extern zugeladen und machen da die eigentlichen Probleme. Beispiel Affiliate oder Network Buttons. Denn da nutzt die beste Seite die in unter 2s läd nichts wenn die Networkbuttons 6-7s brauchen ;|
Peter
YSlow gibt Dir recht mit den DNS Lookups, man bekommt damit auch bei 5 Domains noch die Bestnote.Für Sprites gibt&#039s mehrere Tools wie etwa spritegen.website-performance.org die&#039s sehr einfach machen.
Peter
YSlow gibt Dir recht mit den DNS Lookups, man bekommt damit auch bei 5 Domains noch die Bestnote.

Für Sprites gibt's mehrere Tools wie etwa spritegen.website-performance.org die's sehr einfach machen.
solariz
@Peter: Ja Sprites sind da schon gut aber für die meisten Privatwerbseiten eher unpraktikabel es ist eben um vieles einfacher ein PNG/GIF einzubinden als ein CSS Sprite. Zumal die meisten Blogs / Webseiten ja auf fertige Themes setzen hier ist eher der Theme Author gefragt. Aber auf das Thema gehe ich dann ein ander mal ein ;) War bisher selbst zu "faul" die Seite zu "spriten"

Was die DNS Lookups angeht so ist dies ein Thema was ich denke ich als nächstes aufnehmen werde. dies wird allerdings meist überbewertet. Schaut man sich die meiste Blogs / Webseiten mit ihren zahlreichen Externen JS und Network Buttons an so macht ein einzelner static host recht wenig an Performance verlust. Alleine bei mir sind es über 7 Hosts, wie gesagt meist über die Network Buttons oder "Share It" oder auch Dinge wie Analytics. Hier sind die wahren performance killer versteckt.

Aber da hast du absolut recht YSlow und Pagespeed sind hierzulande noch keine standard Tools beim Webseiten bau. Ich denke aber das wird sich nachdem Google angekündigt hat die Pagespeed in die Suchrelevanz einfließen zu lassen demnächst ändern.
Peter
YSlow gibt Dir recht mit den DNS Lookups, man bekommt damit auch bei 5 Domains noch die Bestnote.Für Sprites gibt's mehrere Tools wie etwa spritegen.website-perfo... die's sehr einfach machen.
★Marco Gö†ze
@Peter: Ja Sprites sind da schon gut aber für die meisten Privatwerbseiten eher unpraktikabel es ist eben um vieles einfacher ein PNG/GIF einzubinden als ein CSS Sprite. Zumal die meisten Blogs / Webseiten ja auf fertige Themes setzen hier ist eher der Theme Author gefragt. Aber auf das Thema gehe ich dann ein ander mal ein ;) War bisher selbst zu "faul" die Seite zu "spriten"Was die DNS Lookups angeht so ist dies ein Thema was ich denke ich als nächstes aufnehmen werde. dies wird allerdings meist überbewertet. Schaut man sich die meiste Blogs / Webseiten mit ihren zahlreichen Externen JS und Network Buttons an so macht ein einzelner static host recht wenig an Performance verlust. Alleine bei mir sind es über 7 Hosts, wie gesagt meist über die Network Buttons oder "Share It" oder auch Dinge wie Analytics. Hier sind die wahren performance killer versteckt.Aber da hast du absolut recht YSlow und Pagespeed sind hierzulande noch keine standard Tools beim Webseiten bau. Ich denke aber das wird sich nachdem Google angekündigt hat die Pagespeed in die Suchrelevanz einfließen zu lassen demnächst ändern.
Peter
Absolut toller Beitrag :)Ne separate Domain für static content ist für kleinere Seiten auch perfekt für n einfaches load balancing. Allerdings sollten Seiten mit vielen kleinen Bildern wie der Deutschlandflage in Deinem Beispiel sich vor allem Image Sprites anschauen. So lässt sich die Anzahl der Elemente die runtergeladen werden müssen sehr stark reduzieren.Bei separaten Domains hat man aber den Nachteil von mehreren DNS lookups.Für nicht besonders technikbewandte (wie mich) sind auch Tools wie Pagespeed ( code.google.com/page-speedd ) von Google oder das YUI tool von Yahoo sehr hilfreich. Kennt hier in Deutschland aber seltsamerweise kaum.Peter
Peter
Absolut toller Beitrag :)

Ne separate Domain für static content ist für kleinere Seiten auch perfekt für n einfaches load balancing. Allerdings sollten Seiten mit vielen kleinen Bildern wie der Deutschlandflage in Deinem Beispiel sich vor allem Image Sprites anschauen. So lässt sich die Anzahl der Elemente die runtergeladen werden müssen sehr stark reduzieren.

Bei separaten Domains hat man aber den Nachteil von mehreren DNS lookups.

Für nicht besonders technikbewandte (wie mich) sind auch Tools wie Pagespeed ( code.google.com/page-speedd ) von Google oder das YUI tool von Yahoo sehr hilfreich. Kennt hier in Deutschland aber seltsamerweise kaum.

Peter
Peter
Absolut toller Beitrag :)Ne separate Domain für static content ist für kleinere Seiten auch perfekt für n einfaches load balancing. Allerdings sollten Seiten mit vielen kleinen Bildern wie der Deutschlandflage in Deinem Beispiel sich vor allem Image Sprites anschauen. So lässt sich die Anzahl der Elemente die runtergeladen werden müssen sehr stark reduzieren.Bei separaten Domains hat man aber den Nachteil von mehreren DNS lookups.Für nicht besonders technikbewandte (wie mich) sind auch Tools wie Pagespeed ( code.google.com/p.p... ) von Google oder das YUI tool von Yahoo sehr hilfreich. Kennt hier in Deutschland aber seltsamerweise kaum.Peter