Na gut, also spiele ich diesen Hotfix ein. Es sollen eine Reihe von Problemen mit der Web-Anwendung behoben werden, außerdem besteht Hoffnung, dass die Anwendung im Browser auf den Clients flotter laufen wird. Nach dem Austausch der aktualisierten Dateien erscheint im Browser ein weißes Fenster. Was lief schief? Könnte es eine Rolle spielen, dass ich zunächst in einer virtuellen Maschine ohne Internetanbindung getestet habe? In der Tat möchte der Browser diesmal Daten von Google abrufen.
Als ich die ausgetauschte Web-Konfigurationsdatei mit der vorherigen Version vergleiche, kann ich eine kleine Änderung entdecken. In der neuen Fassung wird der Zugriff auf ein externes CDN vorgesehen.
Hm, Content Distribution Network, kennt doch jeder (zumindest die praktischen Auswirkungen). Typisches Beispiel: Akamai sorgt mit seinem CDN dafür, dass der Live-Stream oder das Update überall reibungslos ankommen. Millionen von Rechnern in aller Welt stürzen sich nicht über weite Wege auf einen überlasteten Update Server, sondern werden DNS-basiert auf den gewünschten Inhalt auf einem gut erreichbaren Server in ihrer Nähe geleitet.
Aber welchen Content soll das externe Google CDN unserer Anwendung bereitstellen? Unsere eigenen Individualdaten nicht, die sind nirgendwo gespiegelt; die Bildchen, die für die grafische Benutzeroberfläche benötigt werden sind zu klein, was denn sonst? Die Anwendung basiert auf HTLM5 und AJAX. Tatsächlich liefert das CDN Google Hosted Libraries in der Anwendung benötigte JavaScript Bibliotheken aus. (So etwas hätte es etwa auch von Microsoft gegeben.)
Die typischerweise benötigte jQuery Library hat eine Größe von etwa 250 KB. Das ist zwar in heutigen Netzwerken keine gewaltige Datenmenge, aber die Daten müssen eben auf jeden Client geladen werden, bevor für den Nutzer überhaupt etwas passiert. (Bei t3n gibt es sogar Tipps, wie man das Laden von jQuery durch Nutzung von nativem JavaScript vermeidet.)
Wie bei Google Public DNS fragt sich der besonders kritische Nutzer in Europa natürlich, aus welchem Grund das Unternehmen denn diese Dienstleistung unentgeltlich bereit stellt. Was passiert tatsächlich mit all Daten über Seitenaufrufe? Es ist müßig, darüber zu spekulieren.

Ebenso spannend ist wohl die Frage, ob oder wann es bei einer Anwendung sinnvoll sein kann, externe CDN-Dienste zu nutzen. Wenn regelmäßig von weit verteilten Orten auf einen Server zugegriffen werden soll, ist der Nutzen sicherlich schnell erkennbar (zum weiteren Vorteilen in dieser Konstellation siehe M. Kleine). Für eine Intranet-Anwendung erscheint diese Lösung eher ungeeignet. Oder? Man könnte vielleicht einen kleinen überlasteten Internet Information Server davor bewahren, sich zu bemühen Daten auszuliefern, die eh da draußen zu finden sind. Es ist auch nicht völlig ausgeschlossen, dass durch ungünstige Verkabelung von einem Client aus Google schneller zu erreichen ist, als der Server im Keller. Wer weiß.

Auf jeden Fall sollen man bei Rückgriff auf ein CDN nicht vergessen, dass von Zeit zu Zeit kein Internet greifbar ist (Offline Fallback beschrieben bei Scott Hanselman). In meinem praktischen Ausgangspunkt fehlte leider ein solcher Rückgriff auf die lokalen Ressourcen.

Externe JavaScript Bibliotheken