Webdesign

jQuery (und andere Frameworks) direkt via Google Code einbinden

3. Juli 2009
von

Jedem der jQuery schon einmal benutzt hat ist die lokale Einbindung mittels <script type=”text/javascript” src=”js/jquery-1.3.2.js”></script> bekannt. Es gibt allerdings eine Möglichkeit das Framework zu nutzen ohne es lokal zu speichern. Google Code stellt mit den Google AJAX Libraries API das jQuery Framework in der aktueller Version, sowie ältere Ausgaben zum direkten Einbinden bereit. Das spart Traffic und verringert die Ladezeit. jQuery kann auf zwei Arten eingebunden werden.

Einbinden mit direktem Link

Diese Art der Einbindung stellt sich als vertraut dar. In dem Aufruf

<script type="text/javascript" src=" "></script>

wird als Quelle (src=) nicht wie gewohnt der Pfad zum lokalen Speicherort von jQuery angegeben, sondern die URL von Google.

http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js

Somit sieht der komplette Aufruf wie folgt aus:

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

Live Demo im neuen Fenster

Durch den direkten Link ist nur eine Anfrage an den Server notwendig um jQuery einzubinden, somit ist diese Methode (in meinen Tests) schneller als die unten vorgestellte Methode mit google.load().  Auf diese weiße lassen sich natürlich auch andere Versionen von jQuery einbinden. Google stellt momentan (Stand 22.06.09) folgende Versionen bereit:

Version 1.2.3
http://ajax.googleapis.com/ajax/libs/jquery/1.2.3/jquery.min.js
Version 1.2.6
http://ajax.googleapis.com/ajax/libs/jquery/1.3.6/jquery.min.js
Version 1.3.0
http://ajax.googleapis.com/ajax/libs/jquery/1.3.0/jquery.min.js
Version 1.3.1
http://ajax.googleapis.com/ajax/libs/jquery/1.3.1/jquery.min.js
Version 1.3.2
http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js

Einbinden mit google.load()

Die andere Möglichkeit ist die Einbindung mittels google.load(). Hier wird zuerst durch den folgenden Befehl die AJAX Libraries API von Google eingebunden um die google-load() Funktion nutzen zu können.

<script type="text/javascript" src="http://www.google.com/jsapi"></script>

Nun kann jQuery folgendermaßen eingebunden werden.

<script type="text/javascript">
// jQuery laden
google.load("jquery", "1.3.2");
</script>

Live Demo im neuen Fenster

Da hier zuerst die AJAX Libraries API von Google geladen wird sind zwei Anfragen an den Server notwendig, was diese Methode etwas langsamer macht als einen direkten Link.  Durch den direkten Link ist nur eine Anfrage an den Server notwendig um jQuery einzubinden, somit ist diese Methode (in meinen Tests) schneller als die unten vorgestellte Methode mit google.load(). Auch hier stehen natürlich die folgenden Versionen zur Verfügung.

Version 1.2.3
google.load(“jquery”, “1.2.3”);
Version 1.2.6
google.load(“jquery”, “1.2.6”);
Version 1.3.0
google.load(“jquery”, “1.3.0”);
Version 1.3.1
google.load(“jquery”, “1.3.1”);
Version 1.3.2
google.load(“jquery”, “1.3.2”);

Diese Methode bietet sich vor allem an wenn mehrere Frameworks eingebunden werden sollen. Die google.load() Funktionen können einfach nacheinander ausgeführt werden. Beispiel:

<script type="text/javascript">
google.load("jquery", "1.3.2");
google.load("prototype", "1.6");
google.load("scriptaculous", "1.8.2");
google.load("mootools", "1.2.3");
</script>

Versionsauswahl

Bisher war die Rede davon die gewünschte Version durch die komplette Versionsnummer auszuwählen, Google bietet jedoch noch andere Möglichkeiten. Wird anstatt der Vollständigen Nummer “1.2.3” nur “1.2” angegeben wählt Google die die neuste verfügbare Version dieses Zweiges(1.2) aus, hier also “1.2.6”. Somit bewirkt die Angabe von “1” dass hier die Version “1.3.2” eingebunden wird. Diese Versionssemantik funktioniert bei beiden Arten der Einbindung.

Google stellt nicht nur jQuery zur Verfügung

jQuery ist jedoch nicht das einzige Framework, dass sich von Google einbinden lässt. Google stellt momentan(Stand 22.06.09) folgenden Frameworks zur Verfügung:

  • jQuery
  • jQuery UI
  • Prototype
  • script.aculo.us
  • MooTools
  • Dojo
  • SWFObject
  • Yahoo! User Interface Library (YUI)
  • Ext Core

Die Einbindung der verschiedenen Frameworks geschieht auf die gleiche Weise wie sie hier exemplarisch für jQuery beschrieben wurde. (sl)

Student der Kommunikations- und Softwaretechnik

27 Kommentare zu „jQuery (und andere Frameworks) direkt via Google Code einbinden
  1. Sebastian am 3. Juli 2009 um 08:40

    Die Frage ist: Wozu? Wenn ich ein Webprojekt entwickle, liegen alle Abhängigkeiten auf dem selben Rechner bzw. an Orten, die unter meinem Zugriff sind. Die paar KB tun niemandem weh und man hat die vollständige Kontrolle über das, was da passiert. Google wird sicherlich nicht so mir-nichts-dir-nichts die Versionen löschen, aber es ist davon auszugehen, dass Google sämtliche Zugriffe trackt. Die geht es nicht viel an, ob meine Seite deren JQuery nutzt. Die wissen ohnehon schon genug.

  2. Oliver Storm am 3. Juli 2009 um 08:46

    @Sebastian. Das seh ich im Prinzip ganz ähnlich. Das Hauptargument pro einbinden über Google liegt wirklich darin, sollte der User zuvor auf einer anderen Seite gewesen sein welche auch über Google einbindet so hat er die Dateien schon im Cache und muss diese nicht mehr neu laden. Das ist aber auch wirklcih das einzige Argument pro. Contra sind wie du schon sagst Tracking und Abhängigkeit. Ob 54Kb für die minified Version jetzt letztendlich viel oder wenig sind in Zeiten von DSL bleibt wohl jedem selbst überlassen.

  3. Chukki.de am 3. Juli 2009 um 09:02

    @vorredner Ein weiterer Vorteil liegt darin das es nur eine maximale anzahl an HTTP Anfragen pro host gibt. So kann zur selben zeit von einem anderen Host (google) dann Jquery geladen werden.

    Das ist im Prinzip ne Billige Variante des CDN -> http://de.wikipedia.org/wiki/Content_Distribution_Network

  4. Andiministrator am 3. Juli 2009 um 09:08

    Ich bin der Meinung, dass die vorgestellte Variante die Ladezeit für deutsche Webseiten eher verlängert. Die Google Server stehen in den USA und da dürfte die Übertragung länger dauern als von deutschen Servern.

  5. Uwe am 3. Juli 2009 um 09:49

    Haha, der Andi weiß wo die Server von Google stehen. Da wärst Du aber der einzige.

    Ich verstehe das eher so, dass die Google-Server jeweils ganz nahe an mir stehen.

    Was dann ein Vorteil wäre, da ein CDN schneller liefern kann als von einem eigenen Server.

  6. David Hellmann am 3. Juli 2009 um 10:03

    du kannst mit ein paar zeichen ändern alle sachen einbinden ohne alles irgendwo runter zu laden. du kannst ganz einfach auf die neue version gehen ohne viel zu machen. denke darin wird der vorteil liegen.

  7. Pansus am 3. Juli 2009 um 10:27

    Ich will ja nicht nur mosern und Korinthen kacken, aber sowas schmerzt zu sehr, als dass ich die Klappe halten könnte:
    “Auf diese _weiße_ lassen sich natürlich auch andere Versionen von jQuery einbinden.”

  8. Horst am 3. Juli 2009 um 10:43

    kann man jquery nicht auf direkt von jquery selber einbinden? wenn ich mich recht entsinne dann ja…

  9. deweso am 3. Juli 2009 um 10:47

    Ich sehe den Nachteil bei der Verwendung von No-Script oder ähnlichem, denn die Dateien funktionieren nur, wenn die Website (Domain) freigegeben wurde. Auch kann das im IE bei verschärften Sicherheitsregeln zu Problemen führen, da ein Code von einer anderen Domain Auswirkungen auf diese Seite hat.
    Falls der Google Server mal langsamer liefern sollte zieht das dann auch die Performance der eigen Seite herunter.

    Ich denke Pro und Contra sind hier beide legitime Sichtweisen.

  10. Helen am 3. Juli 2009 um 11:41

    Ich widerspreche Andi voll und ganz. Der Standort der Google-Server in den USA müßte sich dann auch beim Googlen bemerkbar machen. Genau das ist aber nicht der Fall. Google ist eine der schnellsten Seiten. Übrigens stehen die Verteilserver von Google nicht in Übersee, wie man als Einbinder aus den Logfiles erfährt.

    Wer eine css-Datei, eine js-Datei und ein Spritebild in die HTML-Datei einbindet, läßt bereits drei Requests vom selben Server laden. Während 1 und 2 laden, steht die dritte Datei in Warteschlange, weil immer nur zwei Requests zugleich geladen werden. Bis das Sprite mit vielleicht 100kB angekommen ist, ist jQuery von den jedem Server der Welt auch schon da.

    Läßt sich übrigens auch messen. Wer eine Reihe einzelner Bilder laden läßt, profitiert vom Fremdserverladen. Manchmal läßt man neben dem Framework ja auch zwei bis drei Skripte laden.

  11. Martin am 3. Juli 2009 um 14:00

    Ich fang mal vorne an: Das Laden von einem anderen Server erfordert eine neue TCP-Verbindung. Das produziert schon mal Wartezeiten und Overhead durch den 3-Wege-Handshake. Es gibt dann mehr Verbindungen, die kürzer andauern. Dadurch lässt sich die vorhandene Bandbreite möglicherweise nicht ganz so gut ausnutzen, da kaum Zeit bleibt, die Geschwindigkeit zu regeln (Stichwort Congestion Control/Avoidance).

    Daneben ist es nicht mehr möglich, die Anfragen mittels Pipelining über bestehende Verbindungen zu senden, was TCP-Handshakes sparen würde und eine genauere Geschwindigkeitsregelung der Verbindung zulässt, da sie länger besteht.

    Außerdem kommen zusätzliche Wartezeiten durch die DNS-Anfragen hinzu.

    Ich möchte das ganze nicht verteufeln, sondern lediglich umfassend informieren. Ich könnte mir etwa vorstellen, dass man den Ladevorgang optimieren kann, wenn man viele kleine und wenige große Objekte hat (etwa in einer Bildergalerie), indem man kleine und große Objekte gezielt in unterschiedliche Verbindungen legt, bei den großen aber möglichst nur eine nutzt: Dann werden die großen Objekte nacheinander geladen und verstopfen nicht die Leitung, werden aber zugleich auch in hoher Geschwindigkeit geladen, da die TCP-Algorithmen genügend Zeit haben, die Geschwindigkeit an die verfügbare Bandbreite anzupassen.

    Der gleiche Effekt wie das Benutzen fremder Server tritt übrigens auch mit Subdomains ein, mit dem Vorteil, dass die Daten des Besuchers nicht an externe Dienste wandern.

  12. Paps am 3. Juli 2009 um 21:21

    Neben den hier schon genannten Vorteilen gibt es noch 3, die man erwähnen sollte.

    Zum einen hat man immer die aktuellste Version des JS Frameworks eingebunden, da Google “Wildcards” unterstützt.
    So reicht der Aufruf von google.load(“jquery”, “1.3”); um immer die aktuellste Version des 1.3 Branches (aktuell 1.3.2) zu haben. google.load(“jquery”, “1”) für die 1er Version usw.
    Spart Zeit, wenn man jQuery auf mehreren Seiten integriert hat, und da neuere Versionen meist deutliche Performancesteigerungen mit sich bringt, ist das schon mal eine Erleichterung.

    Desweiteren sehe ich einen grossen Vorteil im Browsercache. Viele Seiten benutzen JS Frameworks, die sich je nach Einstellungen des Browsers im Cache ablegen. War ein User alllerdings schonmal auf einer Seite, die z.B. jQuery über die Google Api eingebunden hat, so ist diese aus dem Browsercache auch für die eigene verwendbar, was die Ladezeit weiter reduzieren kann.

    Ausserdem muss man jQuery nicht immer laden, sondern hat auch die Möglichkeit, jQuery dynamisch nachzuladen, wenn man es bennötigt. Speziell bei der Integration von Google Maps sehr hilfreich:
    http://code.google.com/intl/de-DE/apis/ajax/documentation/#Dynamic

  13. tekl am 4. Juli 2009 um 01:01

    Und was, wenn Google mal nicht erreichbar ist oder gar auf einer Sperrliste steht?

    • Alexander Trefz am 3. November 2010 um 11:28

      Google auf einer Sperrliste? Das wäre WebDevelopment Selbstmord.
      Falls sie down sind gibt es eine simple Fallback möglichkeit auf eigene Server(oder auch noch das jQuery-CDN, oder das MS-CDN: google plox: html5boilerplate

  14. Helen am 4. Juli 2009 um 02:10

    Ich nochmal. Man sollte sich genau ansehen, welche Elemente die Seite enthält. Ich habe recht große Bilder, da fällt Martins interessante Ergänzung nicht ins Gewicht. Während die css-Datei und zwei Bilder von meinem Server geladen werden, während zugleich jQuery vom Google-Server geladen wird. Liegt jQuery auch auf meinem Server, steht es in der Warteschlange, bis CSS und Bild 1 fertig geladen sind. Es wird erst dann zusammen mit Bild 2 geladen. Auf Slot 3 wartet derweil die eigentliche jQuery-Datei, die die jQuery-Library benutzt. Das sind drei Ladeslots, die nur aufeinanderfolgen können.

    Hat man nur zwei sehr kleine Bilder, die sehr schnell ankommen, kann jQuery ruhig warten. Der Besucher wird da keine Zeitverzögerung bemerken.

    Sind die Library und die eigentlich js-Datei aber oben im Head eingebunden, dann sieht auf dem Platz, wo das Bild stehen soll, vielleicht ein, zwei Sekunden lang das ALT-Attribut.

    Mein Server ist sehr schnell. Trotzdem habe ich bei Versuchen herausgefunden, dass bedingt durch die Ladelogik bei großen Bildern eine Verbsserung durch die Auslagerung erzielt werden kann.

    Google ist nicht so oft außer Betrieb, als dass es es eine schwerwiegende Schwäche wäre angesichts der Masse des normalen Traffics.

  15. Chukki am 4. Juli 2009 um 12:48

    @martin die tcp handshakes die du ansprichst liegen im ms bereich, während eine große Datei (jquery z.B. um die 80kb) die parallel zu anderen großen Bildern geladen werden kann im sekundenbereich liegt. Von daher ist der tcp handshake völlig zu übersehen.

    Sag mir doch bitte warum große Projekte auf CDN Basis entwickelt sind? Da passt ja irgendwas nicht

  16. mono am 29. Juli 2009 um 12:10

    Was soll der quatsch? Ich kann deutlich entspannter schlafen, wenn ich weiß, dass nur Frameworks geladen werden, die auch auf meinem Server liegen. Damit habe ich die Persistenz unter Kontrolle (könnte mir Google diese garantieren?), Updates fliegen nur dann ein, wenn ich das auch will und die paar KB tun in Web2.0-Zeiten niemandem weh.

    • Alexander Trefz am 3. November 2010 um 11:26

      Ja, google Garantiert die Persistenz. Und zwar genau so weit, wie du sie angibst: /1/ ist immer die aktuellste Version. /1.4/ ist immer die aktuellste Version von 1.4 und welch Überraschung, /1.4.3/ ist immer 1.4.3.
      Was zur Hölle sind Web 2.0-Zeiten???? Hast du die geringste Idee wofür Web 2.0 steht?
      70+ kb an *blockierendem* Code tuen Immer Weh. Natürlich kannst du gzipping einschalten und bist bei 26, aber der Vorteil das es einfach im Cache liegt, ist dennoch enorm.

  17. dieterd am 21. Dezember 2009 um 14:21

    Wenn ich mit google.load(“jquery”, “1.3.2”);
    z.B. einbinde dann werden die deutschen
    Umlaute nicht richtig dargestellt?
    Wo soll ich den da den Zeichensatz ändern.
    Also ich habe schon versucht so einzubinden, aber ohne Erfolg

    $(document).ready(function() {
    $(“#selectbox_1″).change(function(){
    var id_hauptkategorie=$(this).children(‘option:selected’).val();
    $(“#selectbox_2″).load(“http://domain.xx/_selectboxen.php”,{value: id_hauptkategorie});
    });

    $(“#selectbox_2″).change(function(){
    var id_hauptkategorie2=$(this).children(‘option:selected’).val();
    $(“#selectbox_3″).load(“http://domain.xx/_selectboxen2.php”,{value: id_hauptkategorie2});
    });

    });

  18. dieterd am 21. Dezember 2009 um 14:24

    Sorry aber er hat meine <java script syntax nicht mit reingeschrieben? Ich schreibe es jetzt nochmals rein so das Ihr den Aufruf seht. Die Tags habe ich weggelassen.

    script type=”text / javascript” charset=”utf-8″

  19. Marcel Weber am 21. Dezember 2009 um 15:23

    @dieterd Kannst du einen link auf deine Seite posten, würde mir da gerne mal anschauen.

    Ich verstehe das Problem mit den Umlauten im moment nicht, sorry

  20. Reinhard Neidl am 24. Juni 2010 um 09:18

    Mit dem Einbinden über Google, können die ihre Statistik (Was, wer, wann, wo, wie) natürlich wieder gut anreichern.

    Google lebt ja davon Daten auszuwerten und
    mit der Einbindung (egal ob via src.. oder google.load)
    “schickst” Du denen ja die Daten freihaus.

    Jeder “Download” wird ja protokolliert.

    Wer seine Frameworks auslagern will, kann sich ja eine SubDomain: libs.mydomain.org anlegen oder eine http://www.mylibsasdfasdfasdf.org.
    Das gilt natürlich auch für Grafiken ;) .
    Wie Verwaltung der Dateien und Verlinkungem ist bei Weitem
    nicht so intensiv, als man im erstem Moment meint.

    • Alexander Trefz am 3. November 2010 um 11:18

      Der Vorteil, wenn jeder es von google.com bezieht ist doch jener, das jQuery damit mit hoher Wahrscheinlichkeit schon im Cache ist, was natürlich nicht der Fall ist wenn man seine eigene dämliche Subdomain benutzt – welchen Vorteil sollte das auch haben?!?!?

      Wenn WebDeveloper angst vor google haben sollten sie einfach den Beruf wechseln, denn sie haben nicht verstanden worum es bei google geht. Außerdem hätten sie ohne Google überhaupt keinen Job…

  21. […] aussehen. Eine Anleitung zum Einbinden von jQuery und andere Frameworks findet sich zum Beispiel in diesem Beitrag bei Dr. Web. Äußerst praktisch ist darüber hinaus auch ScriptSrc.net, wo die Code-Snippets […]

  22. […] binden wir JQuery ein. JQuery benutzen wir sowohl für die AJAX Requests als auch für das weitere Scripting, dann kommt […]

  23. […] Mehr Infos dazu: Google Andere Möglichkeit der Einbindung […]

  24. sorim am 18. November 2012 um 12:50

    Tja,

    sehr oft wenn ich mich bei diversen Seiten anmelde geht alles gut

    manchmal bekomme ich (auf den selben Seiten) die Meldung

    warte auf warten auf ajax.googleapis.com

    und das war es dann – die Anmeldung kommt nicht zustande.
    Obwohl die Seite die ich besuchen wollt nicht down ist – geht nichts mehr.

    Wenn des oft genug passiert vergesse ich die Seite – und wieder ein Kunde verloren der beim Anmeldevorgang gescheitert ist. Macht sich bestimmt gut für die Statistik.

    Leute wenn ihr die Kunden behalten wollt dann vergesst
    ajax.googleapis.com
    und macht es lieber richtig!

Ein Kommentar? Schön!

Wir freuen uns immer über Leser, die durch nützliche und konstruktive Beiträge zum Thema eine Diskussion anstoßen oder den Artikel mit weiteren Informationen anreichern. Alle Kommentare werden in diesem Sinne moderiert. Zum Kommentar-Fairplay gehört für uns auch der Einsatz von rel="nofollow". Bitte verwenden Sie zudem als Namen weder eine Domain noch ein spamverdächtiges Wort. Vielen Dank!