Nachdem die Ladezeit als Rankingfaktor offiziell bestätigt ist, hat bei manchem Webmaster die Alarmglocke Sturm geklingelt. Doch auch wenn ein bisschen Entwarnung gegeben werden kann, so macht es dennoch Sinn, sich die Ladezeiten der eigenen Webseite genauer anzusehen, denn die Ladezeit hat nicht nur einen (momentan geringen) Effekt auf das Ranking bei Google, sondern einen großen Einfluss auf alle anderen Erfolgsfaktoren einer Webseite. So hat Google selbst vor einiger Zeit gelernt, dass eine halbe Sekunde Verzögerung 20% Traffic-Verlust bedeutet. Man könnte sich fragen, ob die Webmaster langsamer Seiten nicht eh schon genug gestraft sind oder warum Facebook-Benutzer sich nicht von langen Wartezeiten abschrecken lassen, aber das soll hier nun nicht das Thema sein.
Stattdessen geht es um konkrete Schritte, wie man die Ladezeiten einer Webseite optimieren kann. Da das nicht kurz mal in einen Artikel zusammengefasst werden kann, wird hieraus eine Serie werden, von der das Netzwerk heute den ersten Teil bildet.
Bevor der Blick auf die Webapplikation selbst geworfen wird, macht es Sinn, sich erst einmal das Netzwerk anzuschauen, in dem die eigene Webseite eingebunden ist. Webhoster werben gerne mit ihrer unglaublich guten Anbindung an das Internet, wie gut es wirklich darum steht, kann nur bedingt getestet werden. Und wenn man mehrere Länder bedienen will mit einer Website, so stellt sich gleich die Frage, ob man nicht in jedem Land einen Server aufstellt (und damit allein für die Suchmaschinenoptimierung bereits einen Vorteil durch die jeweils lokale IP-Adresse erreicht). Als Alternative kommen Content Delivery Networks in Betracht, wo sich Anbieter wie Akamai einer eigenen Infrastruktur bedienen, um die Problemzonen im Internet geschickt zu umgehen. Und es müssen nicht einmal Problemzonen sein, allein schon die Verringerung der Anzahl der Hops zwischen eigenem Server und Browser des Benutzers, flankiert von einer geringeren Netzwerklatenz, bringt eine wesentliche Verbesserung. Allerdings kostet ein CDN Geld und eignet sich daher eher für größere Seiten, insbesondere wenn Videos und andere breitbandige Inhalte ausgeliefert werden müssen.
Für den Rest der Webseitenbetreiber, für die ein CDN noch eine Nummer zu groß ist, ist daher erst einmal die Auswahl des richtigen Hosters wichtig (und danach die Wahl des richtigen Pakets, aber dazu in einem späteren Artikel mehr). Nur, wie testet man die Anbindung eines Hosters? Und selbst wenn die Anbindung gut ist, wer sagt einem, dass die gute Anbindung auch wirklich jedem Hosting-Kunden zur Verfügung steht? So sagt zum Beispiel die Anzahl der Hops zwischen Browser und Server zunächst einmal nicht viel aus, zumal manche Provider diese tarnen; eine Route mit vielen Hops, die aber durch leistungsfähige Router sowie gute Anbindungen gekennzeichnet ist, kann schneller sein als eine Route mit weniger Hops.
EIn wichtiges Werkzeug zum Testen ist Ping, das auf jedem UNIX-Rechner und damit auch Macs mit Mac OS X installiert ist. Pingt man einen Server an, zum Beispiel mit ping unique-labs.de, dann sieht die Antwort so aus:
64 bytes from 217.160.218.90: icmp_seq=186 ttl=51 time=62.830 ms
64 bytes from 217.160.218.90: icmp_seq=187 ttl=51 time=60.163 ms
64 bytes from 217.160.218.90: icmp_seq=188 ttl=51 time=60.960 ms
64 bytes from 217.160.218.90: icmp_seq=189 ttl=51 time=59.628 ms
64 bytes from 217.160.218.90: icmp_seq=190 ttl=51 time=61.065 ms
64 bytes from 217.160.218.90: icmp_seq=191 ttl=51 time=59.849 ms
64 bytes from 217.160.218.90: icmp_seq=192 ttl=51 time=60.269 ms
...
214 packets transmitted, 214 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 59.188/116.719/374.449/75.543 ms
Hier sieht man bereits eine ziemlich hohe Standardabweichung (stddev), die höher sein kann als die kleinste Ping-Zeit. Dabei wird gemessen, wie lange es dauert von dem Absenden einer Anfrage bis zur Ankunft der Antwort. TTL steht dabei für time-to-live und gibt eine Schätzung, wieviele Router zwischen dem Ping-Absender und dem Server liegen, wobei nicht hochgezählt wird, sondern runtergezählt, in diesem Fall von 64. Spannend ist es dann, sich Ping-Zeiten dann von verschiedenen Lokationen in der Welt anzeigen zu lassen, zum Beispiel über just-ping.com. Die Hops selbst lassen sich mit einem traceroute anzeigen. Allerdings kann man sich nicht darauf verlassen, dass die so ermittelte Route auch die übliche Route ist. Bei Ping ist außerdem zu beachten, dass manche Server Ping-Antworten eine niedrigere Prio geben, die Antwort also nicht unbedingt repräsentativ sein muss. Außerdem sollte über einen längeren Zeitraum getestet werden; wenn sich der Bürokollege gerade ein YouTube in HD anschaut, dann kann das schon einen Einfluss haben auf einige Werte 
Tatsächlich ist es allerdings so, dass man sich über diese Netzwerkgeschichten nur Gedanken machen muss, wenn man tatsächlich auch einen Einfluss darauf hat, der über die Auswahl des Hosters hinaus geht. Dies gilt vor allem dann, wenn man selber Server in einem Rechenzentrum unterbringt. Für den Rest der Welt gilt, dass die Auswahl des Hosting-Pakets selbst einen größeren Einfluss hat, vorausgesetzt, dass der Hosting-Anbieter keine obskure Netzwerkanbindung hat, die sich leicht über die oben beschriebenen Verfahren ermitteln ließe.
Im nächsten Teil widmen wir uns dann dem Hosting selbst.
