Alternative: jQuery von Google hosten lassen

Einleitung

Ich habe mich schon öfter gefragt, welche Vorteile es wohl hat, wenn man jQuery von Google hosten lässt statt sich einfach eine Version zu laden und diese einzubinden. An Traffic-Ersparnissen oder gar Speicherplatz kann es ja nun wirklich nicht liegen. In diesem Artikel möchte ich Vor- und Nachteile beleuchten.

Ja, auch ich habe bisher meistens (eigentlich immer) eine Kopie von jQuery geladen und auf dem eigenen Server deponiert. Aber warum sollte man die entsprechenden Daten nicht aus dem CDN (Content Delivery Network) von Google beziehen? Google ist schließlich für schnelle Server und hohe Erreichbarkeit bekannt. Einen Ausfall der Server kann man also beruhigt ausschließen denke ich. Bei mir lag es immer an einem anderen Grund: Ich habe einfach kein gutes Gefühl dabei, wenn essentielle Teile meiner Webseiten irgendwo im Internet verstreut liegen. Außerdem kann ich die Webseite dann nicht offline weiterentwickeln (ok, das ist wirklich etwas konstruiert).

Als letzter und wichtigster Punkt: Das Google CDN ist kostenlos und für jeden ohne Anmeldungen oder Restriktionen verfügbar!

Vorteil: Geringere Verzögerung

Dieser Punkt kommt sicher erst in größeren und internationaleren Projekten zum tragen, aber durch das CDN von Google, lädt jeder Browser des Benutzers die Daten vom nächsten Zugriffspunkt anstatt von dem (eventuell) viel weiter entfernten eigenen Server.

Vorteil: Parallele Verbindungen

Die heutigen Browser beschränken aus Performance-Gründen gerne die Anzahl von parellel Verbindungen zu einem Hostname. In der Zeit wo sonst jQuery vom eigenen Server geladen würde, hat man also noch Reserven um den eigenen Inhalt schneller zu laden. Falls man fünf oder mehr parallele Verbindungen konfiguriert hat, macht sich das natürlich weniger bemerkbar. Die heutigen Breitbandanschlüsse sind im übrigen so schnell, dass dieser Punkt sicherlich nicht sehr stark ins Gewicht fällt. Aber am Ende ist man doch dankbar um jede Millisekunde die man sparen kann, oder?

Vorteil: Caching

Der in meinen Augen größte Benefit ist, dass dank Caching-Mechanismen im Browser die komplette Datei nur einmal geladen werden muss – und das sogar Seitenübergreifend. Kommt man also von einer unbekannten Seite, welche zufällig die selbe Version von jQuery benutzt, muss man diese nicht erneut laden, da Google dann mit einem 304 (Not Modified) antwortet. Es werden also ausschließlich die Header-Informationen ausgetauscht. Das funktioniert sogar, wenn man die Seite komplett neu lädt. So entscheidet also nicht der Browser des Benutzers ob der Cache genutzt werden soll, sondern der Server von Google. Die Daten werden einfach nicht ausgeliefert.

Würde also jede Seite mit jQuery das CDN nutzen, würde man insgesamt sicher einige Megabyte einsparen können.

Implementation

Um die Vorteile des Google CDN zu nutzen, kann man einfach folgenden Code verwenden:

So wird die entsprechende Library in der angegebenen Version geladen. Das ist natürlich etwas irreführend – wo soll da die Performance her kommen? Nun haben wir doch schon zwei Requests statt nur einen. Außerdem ist es für mich schon wieder viel zu viel extra Code. Daher würde ich mich persönlich auf eine etwas gekürzte Version einlassen:

Nun hat man gleich viel Code wie in der vorigen Variante (mit einer Kopie auf dem eigenen Server). Nur der Pfad hat sich geändert.

Als ich den Code das erste Mal gesehen habe, habe ich gedacht der Pfad sei falsch. Immerhin fehlt dort ein http:// oder https://. Dies ist aber vielmehr eine intelligente Lösung um sowohl im http- als auch im http-Kontext zu laufen. Wirklich genial.

Coda

Fazit

Wie man sieht macht es durchaus Sinn, dass man dass CDN von Google nutzt und jQuery von Google hosten lässt. Ich werde jedenfalls in Zukunft etwas anders über diese Möglichkeit denken, anstatt es nur zu belächeln und nicht zu verstehen.

Über

Jahrgang 87, gelernter Softwareentwickler und fast ein Jahrzehnt Erfahrung im Bereich Web-Entwicklung mit PHP und Web-Design. Diese Eigenschaften machen mich zu einem geeigneten und geschätzten Ansprechpartner für die Umsetzung Ihres Projektes. Weiterhin bin ich seit Ende 2013 Magento Certified Developer.