Erik Pöhler

Dies ist im Grunde nichts weiter als eine Übersetzung einiger bekannter Argumente für die Nutzung der bei Google bereitgestellten Javascript-Bibliotheken. Mir ist einfach aufgefallen dass es keinen deutschsprachigen Artikel in den Suchergebnissen zum Thema gab.

Ich bin eigentlich eher skeptisch, wenn es darum geht Daten auszulagern, die man für seine Webseite benötigt. Das Paradebeispiel Flickr hat meine Bedenken vor ein paar Jahren sehr anschaulich gemacht: zahlende Benutzer der Plattform fanden Ihre Bilder plötzlich von einem undurchsichtigen Filtermechanismus gesperrt. Die Bilder waren de facto nicht mehr öffentlich. Der Zorn war groß, doch einer kleinen Minderheit, die Ihre Fotos stattdessen in einem eigenen Photoblog selbst veröffentlichten, entlockte diese neue web 2.0- und AGB-Problematik nur ein zaghaftes schmunzeln.

Worum gehts?

Wer eine Webseite umsetzt und dabei auch noch Wert auf Usability oder einfache Effekte legt, kommt in der Regel in die Versuchung eine der populären Javascript-Bibliotheken wie Prototype, Scriptaculous, Moo-Tools oder jQuery einzusetzen. Diese erleichtern die Arbeit und machen auch nicht-Javascriptern Spaß. Was tut man also? Man speichert die entsprechenden Dateien in einen Ordner auf dem Webspace und bindet sie so oder so ähnlich ein:

1. <script
2. src="/js/jQuery.min.js"
3. type="text/javascript"
4. ></script>

Und genau so macht man es falsch.

Stattdessen sollte man die Google AJAX Libraries oder andere Alternativen verwenden. Und da entstand auch die nicht ganz neue Idee Ressourcen einzusparen, indem man diese häufig verwendeten Dateien nicht jedesmal neu auf einen anderen Webserver lädt, sondern stattdessen auf eine unikate URL verweist. Das hat mindestens 3 Vorteile:

1. <script
2. src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js"
3. type="text/javascript"
4. ></script>

1. Schnellere Ladezeit durch parallele Verbindungen:
   Heutige Browser begrenzen das gleichzeitige Herunterladen von Dateien die auf ein und der selben Domain liegen. Manche Browser können maximal 2 Dateien parallel laden. Das dient zum Schutz der Server, bedeutet aber auch dass moderne Webseiten, die in der Regel viele CSS Dateien, Javaskripte, Bilder, etc. nutzen nur sequentiell, also der Reihe nach ihre Daten an den Browser senden können, selbst wenn der Webserver die nötige Power hätte.
   Darum ist es geschickt (vor allem statische Dokumente wie Bilder, CSS, JS, etc.) auf eine oder gar mehrere Subdomains oder reine Datenserver auszulagern. Der Effekt ist spürbar (und das obwohl natürlich jede Domain einmal über einen DNS aufgelöst werden muss): statt auf die ersten beiden Ressourcen zu warten kann der Browser nun parallel Daten von allen verwendeten Domains und Subdomains laden.
2. Schnellere Auslieferung Dank der Server-Infrastruktur
   Der sogenannte "Otto Normal"-Webseitenschreiber dürfte in der Regel keine Serverfarmen mit weltweit verteilten Rechenzentren sein eigen nennen. Das heißt: egal von welchem noch so entfernten Land ein Besucher kommt, er muss unsere Webseite immer von dem Server laden, auf dem wir diese hosten. Nicht so wenn man sich Amazons Cloudfront (die jQuery Webseite nutzt z.B. selbst diesen Service), oder eben den bei Google gehosteten AJAX-Bibliotheken bedient. Immerhin ein Teil der Daten kann dem Besucher dann aus nächster Nähe geschickt werden. Beide Dienstleister machen das automatisch - und beiden kann man die Erfahrung die sie damit haben nicht absprechen.
3. Optimiertes Caching
   Je mehr Webseiten dies so tun, umso wahrscheinlicher ist es auch, dass die jQuery-Bibliothek bereits im Browsercache eines Besuchers liegt und die Datei gar nicht erst geladen werden muss. Genau wie CSS-Dateien werden nämlich auch Javaskripte gecached. Eine eindeutige, unikate URL zum Javaskript teilt dem Browser also mit, dass jQuery benötigt wird. Dieser hat die Datei aber bereits auf einer zuvor besuchten Webseite geladen und kann so direkt auf die gecachte Datei zurückgreifen.

Mein Fazit:

Die Idee ist nicht neu. Cachefiles.net hat es vor etwa 2 Jahren vorgemacht. Google macht es effektiver und zahlt die Kosten aus der Portokasse. Inzwischen wird das ganze sogar gzip-komprimiert und mit Expires-Headern ausgeliefert, was das Ganze für mich jetzt erst wirklich brauchbar macht.
Ein minimales Restrisiko bleibt: Zum einen besteht die Gefahr, dass Google tatsächlich mal down ist. Zum anderen erlaubt Javaskript so ziemlich alles im Browser des Besuchers bzw. in der Webseite in der es eingebunden ist. Man sollte also zumindest in kritischen Bereichen wo mit vertraulichen Informationen gearbeitet wird, wie z.B. einem Administrationsbereich generell auf externe Javaskripte verzichten.
Natürlich, natürlich… um Angst vor einem bei Google gehosteten jQuery haben zu müssen, muss Google ersteinmal über Nacht extremst böse werden oder jemand all ihre Server hacken - was ich für absolut unrealistisch halte… aber hey, ich will auch nicht Schuld sein, wenns jemand übertreibt oder unachtsam ist.