Montag, 1. April 2013

Google Hosted Libraries: Oder wieso lokales Hosten falsch ist

Da ich immer wieder sehe, dass Web-Site-Entwickler JavaScript Libraries downloaden und von ihrem eigenen Hosting-Account aus bereitstellen, schreibe ich nun in diesem Artikel, wieso man dies nicht tun sollte, respektive wie man es korrekt angehen soll.

Dabei erkläre ich was hosted libraries sind, und gehe dabei auf das Google-Ajax-API Content Delivery Network ein. Der schnellen Übersichtlichkeit halber aber vorweg:

Falsch:

<script type="text/javascript"
       
src="fileadmin/scripts/jquery/jquery.min.js">
</script>


Richtig:

<script type="text/javascript"
       
src="http://ajax.googleapis.com/ajax/libs/jquery/1.8.3/jquery.min.js">
</script>

Was ist falsch am Hosten von JS Bibliotheken?

Beispiel jQuery: Meistens bleibt es nicht nur bei einer zu ladenden Datei, sondern es werden noch etliche Submodule in eigenen Dateien mitgeladen (z.B. jquery-ui, jquery-colorbox, usw.). Ein Browser lädt diese Dateien im Grunde genommen hintereinander herunter (resp. gemäss HTTP 1.1 Standard RFC 2616 Sektion 8 zwei Downloads parallel, siehe auch mein Blog-Artikel zur Download-Parallelisierung). Während nun diese Downloads getätigt werden, werden keine weiteren Ressourcen der Website heruntergeladen, bis alle Module fertig geladen haben. Das Laden der Website verzögert sich, bis alle für die Bibliothek erforderlichen Files gedownloadet wurden. Doch worauf will ich hinaus?

Ebenfalls im HTTP 1.1 Standard ist beschrieben, dass die Limitierung von parallelen Downloads pro Host gilt. Wenn wir also die Javascripts von woanders her laden, dann geschieht dies in einer "eigenen Welt", und unsere Website kann munter die Ressourcen herunterladen, die es für die effektive Anzeige auch braucht. Der Download unserer Bilder, CSS usw. wird nicht blockiert durch Library-Downloads. Dazu kommt noch, dass wir die Bandbreite etwas schonen.

Was sind die Vorteile?

  1. Die Libraries werden von Google auch mit Cache-Header versehen, welche 1 Jahr gültig sind. Da nun weltweit viele Websites das CDN verwenden, ist die Chance gross einen Besucher zu haben, der die Library bereits in seinem Cache hat. Damit muss der User die Library nicht nochmals downloaden, sondern behält sie in seinem Browser-Cache für alle Websites, welche die Library verwenden.
  2. Kein Hosting, keine Bandbreite, kein Storage benötigt für die Libraries
  3. Einfaches Umschalten auf eine neuere Library-Version: Anstatt die neue Version zu downloaden und zu installieren, kann einfach das script-src Attribut dahingehend geändert werden, dass eine andere Version angefordert werden soll.
  4. Profitieren von der massiven Performance des Google-CDN

Kontras?

Wenn ich Leute frage, wieso sie die Libraries nicht über Google API CDN beziehen, sondern selber bereitstellen, erhalte ich in der Regel die folgende Antwort: Mein Web-Hoster ist schneller als das Google CDN, ich habs gemessen!

Das mag sein, solange der Web-Hoster mehr oder weniger dein Nachbar ist. Was aber, wenn ein User aus New-York deine Seite abruft? Ein 3-Way TCP Handshake zwischen Europa und USA hat einfach seine rund 60-80ms Latenz, schon nur das Licht braucht seine 30ms Reisezeit. Das Google CDN ist aber dezentral gehostet - sprich der Amerikaner kriegt seine JavaScript Libraries von einem dort lokalen CDN, und in Europa kriegen wir sie von einem für uns lokalen CDN. Global gesehen, ist es also vernünftiger, die CDN zu verwenden. Man kauft seine Kopfsalate auch nicht Übersee, wenn man sie im Supermarkt gegenüber kriegen könnte.

Was ich auch schon hörte ist, dass Leute Probleme damit haben, die Kontrolle über ihre JavaScript Libraries "weg zu geben". Ich denke, dieses Argument ist objektiv und sachlich relativ schnell zu entkräften. Ein Content Delivery Network ist weltweit dezentral angelegt, und die Leute von Google wissen wohl, wie man hoch verfügbare Services bereitstellt. Eine Google CDN Downtime ist mir zumal noch nie zu Ohren gekommen, während ich von verschiedenen Hostern schon Downtimes wegen "Wartungsarbeiten" in Kauf nehmen musste.

Welches CDN soll ich wählen (Daten aus 2012)?

Um beim Beispiel von jQuery zu bleiben, gibt es drei grosse CDN, welche diese Libraries anbieten: Google, Microsoft und MediaTemple. Es stellt sich die Frage, welches CDN gewählt werden soll. Das Unternehmen Pingdom (ein Monitoring Service Anbieter) hat über 30 Tage hinweg jeweils einmal pro Minute eine Library von den drei CDN bezogen, und nebenstehende Grafik erstellt.

Daraus ist ersichtlich, dass Media-Temple die besten Antwortzeiten hat. Wenn der Content aber über HTTPS geliefert werden sollte, dann ist das Google CDN die erste Wahl.

Weitere Libraries?

Google hostet nebst jQuery noch folgende Libraries. Ist eine Version einmal veröffentlicht, wird diese unendlich lang gehostet:

Keine Kommentare:

Kommentar veröffentlichen