Spaces. Smartes Cloud Hosting für anspruchsvolle Webprojekte. Loslegen und Spaces testen. Von Mittwald.
Marcel Weber 3. Juli 2009

jQuery (und andere Frameworks) direkt via Google Code einbinden

Jedem der jQuery schon ein­mal benutzt hat ist die loka­le Einbindung mit­tels <script type=“text/javascript” src=“js/jquery-1.3.2.js”></script> bekannt. Es gibt aller­dings eine Möglichkeit das Framework zu nut­zen ohne es lokal zu spei­chern. Google Code stellt mit den Google AJAX Libraries API das jQuery Framework in der aktu­el­ler Version, sowie älte­re Ausgaben zum direk­ten Einbinden bereit. Das spart Traffic und ver­rin­gert die Ladezeit. jQuery kann auf zwei Arten ein­ge­bun­den wer­den.

Einbinden mit direktem Link

Diese Art der Einbindung stellt sich als ver­traut dar. In dem Aufruf

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

wird als Quelle (src=) nicht wie gewohnt der Pfad zum loka­len Speicherort von jQuery ange­ge­ben, son­dern die URL von Google.

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

Somit sieht der kom­plet­te 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 neu­en Fenster

Durch den direk­ten Link ist nur eine Anfrage an den Server not­wen­dig um jQuery ein­zu­bin­den, somit ist die­se Methode (in mei­nen Tests) schnel­ler als die unten vor­ge­stell­te Methode mit google.load().  Auf die­se wei­ße las­sen sich natür­lich auch ande­re Versionen von jQuery ein­bin­den. Google stellt momen­tan (Stand 22.06.09) fol­gen­de 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 ande­re Möglichkeit ist die Einbindung mit­tels google.load(). Hier wird zuerst durch den fol­gen­den Befehl die AJAX Libraries API von Google ein­ge­bun­den um die goog­le-load() Funktion nut­zen zu kön­nen.

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

Nun kann jQuery fol­gen­der­ma­ßen ein­ge­bun­den wer­den.

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

Live Demo im neu­en Fenster

Da hier zuerst die AJAX Libraries API von Google gela­den wird sind zwei Anfragen an den Server not­wen­dig, was die­se Methode etwas lang­sa­mer macht als einen direk­ten Link.  Durch den direk­ten Link ist nur eine Anfrage an den Server not­wen­dig um jQuery ein­zu­bin­den, somit ist die­se Methode (in mei­nen Tests) schnel­ler als die unten vor­ge­stell­te Methode mit google.load(). Auch hier ste­hen natür­lich die fol­gen­den 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 bie­tet sich vor allem an wenn meh­re­re Frameworks ein­ge­bun­den wer­den sol­len. Die google.load() Funktionen kön­nen ein­fach nach­ein­an­der aus­ge­führt wer­den. 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ünsch­te Version durch die kom­plet­te Versionsnummer aus­zu­wäh­len, Google bie­tet jedoch noch ande­re Möglichkeiten. Wird anstatt der Vollständigen Nummer “1.2.3” nur “1.2” ange­ge­ben wählt Google die die neus­te ver­füg­ba­re Version die­ses Zweiges(1.2) aus, hier also “1.2.6”. Somit bewirkt die Angabe von “1” dass hier die Version “1.3.2” ein­ge­bun­den wird. Diese Versionssemantik funk­tio­niert bei bei­den Arten der Einbindung.

Google stellt nicht nur jQuery zur Verfügung

jQuery ist jedoch nicht das ein­zi­ge Framework, dass sich von Google ein­bin­den lässt. Google stellt momentan(Stand 22.06.09) fol­gen­den Frameworks zur Verfügung:

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

Die Einbindung der ver­schie­de­nen Frameworks geschieht auf die glei­che Weise wie sie hier exem­pla­risch für jQuery beschrie­ben wur­de. (sl)

Marcel Weber

Student der Kommunikations- und Softwaretechnik

25 Kommentare

  1. Tja,

    sehr oft wenn ich mich bei diver­sen Seiten anmel­de geht alles gut

    manch­mal bekom­me ich (auf den sel­ben Seiten) die Meldung

    war­te auf war­ten auf ajax.googleapis.com

    und das war es dann – die Anmeldung kommt nicht zustan­de.
    Obwohl die Seite die ich besu­chen wollt nicht down ist – geht nichts mehr.

    Wenn des oft genug pas­siert ver­ges­se ich die Seite – und wie­der ein Kunde ver­lo­ren der beim Anmeldevorgang geschei­tert ist. Macht sich bestimmt gut für die Statistik.

    Leute wenn ihr die Kunden behal­ten wollt dann ver­gesst
    ajax.googleapis.com
    und macht es lie­ber rich­tig!

  2. Mit dem Einbinden über Google, kön­nen die ihre Statistik (Was, wer, wann, wo, wie) natür­lich wie­der gut anrei­chern.

    Google lebt ja davon Daten aus­zu­wer­ten und
    mit der Einbindung (egal ob via src.. oder google.load)
    “schickst” Du denen ja die Daten frei­haus.

    Jeder “Download” wird ja pro­to­kol­liert.

    Wer sei­ne Frameworks aus­la­gern will, kann sich ja eine SubDomain: libs.mydomain.org anle­gen oder eine http://www.mylibsasdfasdfasdf.org.
    Das gilt natür­lich auch für Grafiken ;) .
    Wie Verwaltung der Dateien und Verlinkungem ist bei Weitem
    nicht so inten­siv, als man im ers­tem Moment meint.

    • Der Vorteil, wenn jeder es von google.com bezieht ist doch jener, das jQuery damit mit hoher Wahrscheinlichkeit schon im Cache ist, was natür­lich nicht der Fall ist wenn man sei­ne eige­ne däm­li­che Subdomain benutzt – wel­chen Vorteil soll­te das auch haben?!?!?

      Wenn WebDeveloper angst vor goog­le haben soll­ten sie ein­fach den Beruf wech­seln, denn sie haben nicht ver­stan­den wor­um es bei goog­le geht. Außerdem hät­ten sie ohne Google über­haupt kei­nen Job…

  3. @dieterd Kannst du einen link auf dei­ne Seite pos­ten, wür­de mir da ger­ne mal anschau­en.

    Ich ver­ste­he das Problem mit den Umlauten im moment nicht, sor­ry

  4. Sorry aber er hat mei­ne <java script syn­tax nicht mit rein­ge­schrie­ben? Ich schrei­be es jetzt noch­mals rein so das Ihr den Aufruf seht. Die Tags habe ich weg­ge­las­sen.

    script type=“text / java­script” charset=“utf-8”

  5. Wenn ich mit google.load(“jquery”, “1.3.2”);
    z.B. ein­bin­de dann wer­den die deut­schen
    Umlaute nicht rich­tig dar­ge­stellt?
    Wo soll ich den da den Zeichensatz ändern.
    Also ich habe schon ver­sucht so ein­zu­bin­den, 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});
    });

    });

  6. Was soll der quatsch? Ich kann deut­lich ent­spann­ter schla­fen, wenn ich weiß, dass nur Frameworks gela­den wer­den, die auch auf mei­nem Server lie­gen. Damit habe ich die Persistenz unter Kontrolle (könn­te mir Google die­se garan­tie­ren?), Updates flie­gen nur dann ein, wenn ich das auch will und die paar KB tun in Web2.0-Zeiten nie­man­dem weh.

    • Ja, goog­le Garantiert die Persistenz. Und zwar genau so weit, wie du sie angibst: /1/ ist immer die aktu­ells­te Version. /1.4/ ist immer die aktu­ells­te 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 gerings­te Idee wofür Web 2.0 steht?
      70+ kb an *blo­ckie­ren­dem* Code tuen Immer Weh. Natürlich kannst du gzip­ping ein­schal­ten und bist bei 26, aber der Vorteil das es ein­fach im Cache liegt, ist den­noch enorm.

  7. @martin die tcp hand­shakes die du ansprichst lie­gen im ms bereich, wäh­rend eine gro­ße Datei (jque­ry z.B. um die 80kb) die par­al­lel zu ande­ren gro­ßen Bildern gela­den wer­den kann im sekun­den­be­reich liegt. Von daher ist der tcp hand­shake völ­lig zu über­se­hen.

    Sag mir doch bit­te war­um gro­ße Projekte auf CDN Basis ent­wi­ckelt sind? Da passt ja irgend­was nicht

  8. Ich noch­mal. Man soll­te sich genau anse­hen, wel­che Elemente die Seite ent­hält. Ich habe recht gro­ße Bilder, da fällt Martins inter­es­san­te Ergänzung nicht ins Gewicht. Während die css-Datei und zwei Bilder von mei­nem Server gela­den wer­den, wäh­rend zugleich jQuery vom Google-Server gela­den wird. Liegt jQuery auch auf mei­nem Server, steht es in der Warteschlange, bis CSS und Bild 1 fer­tig gela­den sind. Es wird erst dann zusam­men mit Bild 2 gela­den. Auf Slot 3 war­tet der­weil die eigent­li­che jQuery-Datei, die die jQuery-Library benutzt. Das sind drei Ladeslots, die nur auf­ein­an­der­fol­gen kön­nen.

    Hat man nur zwei sehr klei­ne Bilder, die sehr schnell ankom­men, kann jQuery ruhig war­ten. Der Besucher wird da kei­ne Zeitverzögerung bemer­ken.

    Sind die Library und die eigent­lich js-Datei aber oben im Head ein­ge­bun­den, dann sieht auf dem Platz, wo das Bild ste­hen soll, viel­leicht ein, zwei Sekunden lang das ALT-Attribut.

    Mein Server ist sehr schnell. Trotzdem habe ich bei Versuchen her­aus­ge­fun­den, dass bedingt durch die Ladelogik bei gro­ßen Bildern eine Verbsserung durch die Auslagerung erzielt wer­den kann.

    Google ist nicht so oft außer Betrieb, als dass es es eine schwer­wie­gen­de Schwäche wäre ange­sichts der Masse des nor­ma­len Traffics.

  9. Und was, wenn Google mal nicht erreich­bar ist oder gar auf einer Sperrliste steht?

    • Google auf einer Sperrliste? Das wäre WebDevelopment Selbstmord.
      Falls sie down sind gibt es eine simp­le Fallback mög­lich­keit auf eige­ne Server(oder auch noch das jQuery-CDN, oder das MS-CDN: goog­le plox: html5boilerplate

  10. Neben den hier schon genann­ten Vorteilen gibt es noch 3, die man erwäh­nen soll­te.

    Zum einen hat man immer die aktu­ells­te Version des JS Frameworks ein­ge­bun­den, da Google “Wildcards” unter­stützt.
    So reicht der Aufruf von google.load(“jquery”, “1.3”); um immer die aktu­ells­te Version des 1.3 Branches (aktu­ell 1.3.2) zu haben. google.load(“jquery”, “1”) für die 1er Version usw.
    Spart Zeit, wenn man jQuery auf meh­re­ren Seiten inte­griert hat, und da neue­re Versionen meist deut­li­che Performancesteigerungen mit sich bringt, ist das schon mal eine Erleichterung.

    Desweiteren sehe ich einen gros­sen Vorteil im Browsercache. Viele Seiten benut­zen JS Frameworks, die sich je nach Einstellungen des Browsers im Cache able­gen. War ein User all­ler­dings schon­mal auf einer Seite, die z.B. jQuery über die Google Api ein­ge­bun­den hat, so ist die­se aus dem Browsercache auch für die eige­ne ver­wend­bar, was die Ladezeit wei­ter redu­zie­ren kann.

    Ausserdem muss man jQuery nicht immer laden, son­dern hat auch die Möglichkeit, jQuery dyna­misch nach­zu­la­den, wenn man es ben­nö­tigt. Speziell bei der Integration von Google Maps sehr hilf­reich:
    http://code.google.com/intl/de-DE/apis/ajax/documentation/#Dynamic

    • Wo liegt der Fehler?

      Naja, viel­leicht ist’s auch nur ein Tippfehler.

      Mit dem ange­ge­be­nen Link wird bei Google nichts gefun­den.
      Könnte das viel­leicht auch bei Google-jque­ry-appis pas­sie­ren.

  11. Ich fang mal vor­ne an: Das Laden von einem ande­ren Server erfor­dert eine neue TCP-Verbindung. Das pro­du­ziert schon mal Wartezeiten und Overhead durch den 3-Wege-Handshake. Es gibt dann mehr Verbindungen, die kür­zer andau­ern. Dadurch lässt sich die vor­han­de­ne Bandbreite mög­li­cher­wei­se nicht ganz so gut aus­nut­zen, da kaum Zeit bleibt, die Geschwindigkeit zu regeln (Stichwort Congestion Control/Avoidance).

    Daneben ist es nicht mehr mög­lich, die Anfragen mit­tels Pipelining über bestehen­de Verbindungen zu sen­den, was TCP-Handshakes spa­ren wür­de und eine genaue­re Geschwindigkeitsregelung der Verbindung zulässt, da sie län­ger besteht.

    Außerdem kom­men zusätz­li­che Wartezeiten durch die DNS-Anfragen hin­zu.

    Ich möch­te das gan­ze nicht ver­teu­feln, son­dern ledig­lich umfas­send infor­mie­ren. Ich könn­te mir etwa vor­stel­len, dass man den Ladevorgang opti­mie­ren kann, wenn man vie­le klei­ne und weni­ge gro­ße Objekte hat (etwa in einer Bildergalerie), indem man klei­ne und gro­ße Objekte gezielt in unter­schied­li­che Verbindungen legt, bei den gro­ßen aber mög­lichst nur eine nutzt: Dann wer­den die gro­ßen Objekte nach­ein­an­der gela­den und ver­stop­fen nicht die Leitung, wer­den aber zugleich auch in hoher Geschwindigkeit gela­den, da die TCP-Algorithmen genü­gend Zeit haben, die Geschwindigkeit an die ver­füg­ba­re Bandbreite anzu­pas­sen.

    Der glei­che Effekt wie das Benutzen frem­der Server tritt übri­gens auch mit Subdomains ein, mit dem Vorteil, dass die Daten des Besuchers nicht an exter­ne Dienste wan­dern.

  12. Ich wider­spre­che Andi voll und ganz. Der Standort der Google-Server in den USA müß­te sich dann auch beim Googlen bemerk­bar machen. Genau das ist aber nicht der Fall. Google ist eine der schnells­ten Seiten. Übrigens ste­hen 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 ein­bin­det, läßt bereits drei Requests vom sel­ben Server laden. Während 1 und 2 laden, steht die drit­te Datei in Warteschlange, weil immer nur zwei Requests zugleich gela­den wer­den. Bis das Sprite mit viel­leicht 100kB ange­kom­men ist, ist jQuery von den jedem Server der Welt auch schon da.

    Läßt sich übri­gens auch mes­sen. Wer eine Reihe ein­zel­ner Bilder laden läßt, pro­fi­tiert vom Fremdserverladen. Manchmal läßt man neben dem Framework ja auch zwei bis drei Skripte laden.

  13. Ich sehe den Nachteil bei der Verwendung von No-Script oder ähn­li­chem, denn die Dateien funk­tio­nie­ren nur, wenn die Website (Domain) frei­ge­ge­ben wur­de. Auch kann das im IE bei ver­schärf­ten Sicherheitsregeln zu Problemen füh­ren, da ein Code von einer ande­ren Domain Auswirkungen auf die­se Seite hat.
    Falls der Google Server mal lang­sa­mer lie­fern soll­te zieht das dann auch die Performance der eigen Seite her­un­ter.

    Ich den­ke Pro und Contra sind hier bei­de legi­ti­me Sichtweisen.

  14. kann man jque­ry nicht auf direkt von jque­ry sel­ber ein­bin­den? wenn ich mich recht ent­sin­ne dann ja…

  15. Ich will ja nicht nur mosern und Korinthen kacken, aber sowas schmerzt zu sehr, als dass ich die Klappe hal­ten könn­te:
    “Auf die­se _weiße_ las­sen sich natür­lich auch ande­re Versionen von jQuery ein­bin­den.”

  16. du kannst mit ein paar zei­chen ändern alle sachen ein­bin­den ohne alles irgend­wo run­ter zu laden. du kannst ganz ein­fach auf die neue ver­si­on gehen ohne viel zu machen. den­ke dar­in wird der vor­teil lie­gen.

  17. Haha, der Andi weiß wo die Server von Google ste­hen. Da wärst Du aber der ein­zi­ge.

    Ich ver­ste­he das eher so, dass die Google-Server jeweils ganz nahe an mir ste­hen.

    Was dann ein Vorteil wäre, da ein CDN schnel­ler lie­fern kann als von einem eige­nen Server.

  18. Ich bin der Meinung, dass die vor­ge­stell­te Variante die Ladezeit für deut­sche Webseiten eher ver­län­gert. Die Google Server ste­hen in den USA und da dürf­te die Übertragung län­ger dau­ern als von deut­schen Servern.

  19. @vorredner Ein wei­te­rer Vorteil liegt dar­in das es nur eine maxi­ma­le anzahl an HTTP Anfragen pro host gibt. So kann zur sel­ben zeit von einem ande­ren Host (goog­le) dann Jquery gela­den wer­den.

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

  20. @Sebastian. Das seh ich im Prinzip ganz ähn­lich. Das Hauptargument pro ein­bin­den über Google liegt wirk­lich dar­in, soll­te der User zuvor auf einer ande­ren Seite gewe­sen sein wel­che auch über Google ein­bin­det so hat er die Dateien schon im Cache und muss die­se nicht mehr neu laden. Das ist aber auch wirk­lcih das ein­zi­ge Argument pro. Contra sind wie du schon sagst Tracking und Abhängigkeit. Ob 54Kb für die mini­fied Version jetzt letzt­end­lich viel oder wenig sind in Zeiten von DSL bleibt wohl jedem selbst über­las­sen.

  21. Die Frage ist: Wozu? Wenn ich ein Webprojekt ent­wick­le, lie­gen alle Abhängigkeiten auf dem sel­ben Rechner bzw. an Orten, die unter mei­nem Zugriff sind. Die paar KB tun nie­man­dem weh und man hat die voll­stän­di­ge Kontrolle über das, was da pas­siert. Google wird sicher­lich nicht so mir-nichts-dir-nichts die Versionen löschen, aber es ist davon aus­zu­ge­hen, dass Google sämt­li­che Zugriffe trackt. Die geht es nicht viel an, ob mei­ne Seite deren JQuery nutzt. Die wis­sen ohne­hon schon genug.

Schreibe einen Kommentar zu Alexander Trefz Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.