jQuery (und andere JavaScript-Bibliotheken) im CDN
Nach der EinfĂĽhrung von jQuery in einem Projekt stellte sich die Frage, ob die Bibliotheksdateien auf der eigenen Server-Infrastruktur vorgehalten werden sollen oder ob man eine der verfĂĽgbaren Content-Delivery-Network-Infrastrukturen nutzen soll.
- Kai König
In einem unserer aktuellen Projekte arbeiten wir mit jQuery als JavaScript-Kernbibliothek im Frontend der Applikation. Dazu kommen verschiedene jQuery-Plugins sowie einige Komponenten der jQuery UI-Bibliotheken.
In bestimmten Legacy-Elementen der Anwendung werden eine Vielzahl von anderen JavaScript-Frameworks und individuell entwickelte Bibliotheken verwendet. Im Zuge der Konsolidierung der gesamten Anwendungsplattform war ein Ziel des IT-Managements, diesen Wildwuchs einzudämmen und für Neu- oder Weiterentwicklung auf jQuery zu setzen und nur noch in gut begründeten Einzelfällen Ausnahmen zuzulassen.
Das ist aber gar nicht das eigentliche Thema dieses Posts. Nach erfolgter EinfĂĽhrung von jQuery war eine der sich stellenden Fragen ob die Bibliotheksdateien auf der eigenen Server-Infrastruktur vorgehalten werden sollen oder ob man eine der verfĂĽgbaren Content-Delivery-Network-Infrastrukturen nutzen soll. So bieten sowohl Google als auch Microsoft jQuery und jQuery UI auf ihren CDN-Servern an.
Auf den ersten Blick wĂĽrde man diese Entscheidung doch als sogenannten "No Brainer" bezeichnen, oder? Die Vorteile scheinen ganz klar zu ĂĽberwiegen:
- CDN basieren in der Regel auf weltweit verteilen und redundanten Infrastrukturen, sodass die Ladezeiten der Dateien fĂĽr nahezu jeden Ort der Welt optimiert sein sollten.
- Die JavaScript-Dateien werden nicht vom Kundenserver geladen, sodass sich eine Reduzierung des Traffics einstellen sollte.
- "Netzwerk-Effekt" für Caching – wenn viele Leute jQuery in einer bestimmten Version vom Google oder Microsoft CDN laden werden die Dateien im Browser vorgehalten und müssen auch für andere Webseiten oder – Anwendungen ggf. nicht mehr neu geladen werden.
EinigermaĂźen offensichtlich ist das Problem, dass auch das beste und redundanteste CDN einmal nicht erreichbar sein kann. In diesem Fall wĂĽrden die Anwendungen des Kunden auf den eigenen Servern problemlos erreichbar sein und funktionieren, sich allerdings durch das Fehlen der jQuery-Bibliotheken seltsam verhalten (im besten Fall) oder komplett zusammenbrechen.
Also muss ein Fallback her – etwas wie: wir versuchen die Bibliotheken vom CDN zu laden, und wenn das nicht klappt, dann erzeugen wir mit DOM-Manipulation einen <script>-Tag, der auf eine lokale Version der .js-Dateien zugreift. Das ist auch soweit prima – nur in der Realität durch eine Vielzahl von Seiteneffekten nicht so trivial, wie man denken mag.
Zieht man nun diese Seiteneffekte und potenziellen Probleme in Betracht, stellt sich die Situation schon leicht anders dar. Das ist aber bei weitem nicht alles, so hängt die "Stärke" des Netzwerk-Effekts aus dem dritten Punkt der obigen Aufzählung massiv von der Verbreitung und Nutzung der CDN-gehosteten Bibliotheken ab. Billy Hoffman von zoompf.com hat diesen und andere Gesichtspunkte in einem Blogpost näher untersucht. Die Diskussion in den Kommentaren zum Post ist sehr lesenswert.
Das Fazit ist: Die Nutzung von JavaScript-Bibliotheken in einem CDN ist eben kein "No Brainer", sondern immer im Einzelfall abzuwägen. Im Fall des hier angesprochenen Kunden haben wir uns dafür entschieden, die öffentlichen CDN-Versionen nicht zu nutzen, sondern auf selbst gehostete Dateien zuzugreifen. Ein weiterer Grund für diese Entscheidung ist, dass der Kunde bereits eine CDN-artige, weltweite Hosting-Infrastruktur nutzt und der Vorteil eines Microsoft- oder Google-CDNs daher sowieso deutlich geringer ausgefallen wäre.
