Pagespeed – Distinct / Static Hosts

  1. tcpip.wtf
  2. Posts
  3. Pagespeed – Distinct / Static Hosts

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),[…] 9 Da 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.

✉ MG// CEST

Follow Icon
Don’t miss out and subscribe by email:
Don't worry! NO Spam and FREE; Receive a summarizing email for new posts, easy to unsubscribe at any time.
← Other Blog Posts