Google CDN Namenskonventionen (und Sie)

Das haben Sie schon einmal gesehen

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js"></script>

Dies ist eine Möglichkeit, eine JavaScript-Bibliothek wie jQuery direkt vom Google CDN (Content Delivery Network) zu laden. Sie können diese von ScriptSrc.net schnell kopieren und einfügen.

Sehen Sie in der obigen URL, wie sie sich speziell auf 1.4.4 bezieht? Dieser kleine Teil der URL kann geändert werden. Vielleicht haben Sie ihn schon einmal so verwendet gesehen.

/1.4.4/	Lädt diese ganz bestimmte Version von jQuery, die sich niemals ändern wird.
/1.4/	Heute wird dies 1.4.4 laden. Wenn und wann jQuery zu 1.4.5 wechselt, wird diese URL darauf verweisen. Wenn und wann jQuery zu 1.5 wechselt, wird es auf die letzte Veröffentlichung von 1.4 verlinken.
/1/	Heute wird dies 1.4.4 laden. Wenn und wann jQuery zu 1.5 wechselt, wird diese URL nun darauf verweisen. Wenn und wann jQuery zu 2.0 wechselt, wird es auf die letzte Veröffentlichung von jQuery 1.x verlinken.

Soweit ich weiß, gibt es keine wirklich zuverlässige Methode, um auf den „absolut neuesten“ Build von jQuery zu verlinken (z. B. der, der immer noch funktionieren würde, wenn jQuery zu 2.0 wechselt und Nachtschicht-Builds einschließt). Lassen Sie uns herausfinden, welche wir verwenden sollten.

Eine kleine Erinnerung, warum wir das überhaupt tun

Die Gründe dafür sind am besten von Dave Ward dargelegt worden

1. Reduzierte Latenz – Datei wird von einem buchstäblich-geografisch näheren Server geliefert.
2. Erhöhte Parallelität – Browser begrenzen, wie viele Ressourcen gleichzeitig von einer einzelnen Domain heruntergeladen werden können, einige bis zu zwei. Da dies google.com und nicht yoursite.com ist, zählt es nicht zu diesem Limit.
3. Bessere Zwischenspeicherung – Es besteht eine ziemlich gute Chance, dass Ihre Besucher bereits eine Kopie dieser Datei im Cache ihres Browsers haben, was die schnellstmögliche Methode zum Laden ist.

Dem würde ich hinzufügen

4. Spart Bandbreite – Die minimierte Version von jQuery 1.4.4 ist 82k. Wenn Sie also 1.000.000 Seitenaufrufe ohne lokalen Cache hätten, wären das 78 GB Datenübertragung, was nicht unerheblich ist.

Caching-Header

Nummer 1 und 2 oben helfen unabhängig davon, aber das Caching bedarf einer etwas ausführlicheren Diskussion. Es stellt sich heraus, dass die von Ihnen gewählte Namenskonvention für den Caching-Aspekt sehr wichtig ist. Paul Irish hat einige grundlegende Forschungsergebnisse dazu. Ich habe diese Forschung wiederholt und die Ergebnisse sind unten aufgeführt. Es stellt sich heraus, dass nur die Verlinkung auf eine direkte exakte Version ordnungsgemäße Caching-Header aufweist.

/1.4.4/	Ein Jahr	public, max-age=31536000	Screenshot
/1.4/	Eine Stunde, streng	public, must-revalidate, proxy-revalidate, max-age=3600	Screenshot
/1/	Eine Stunde, streng	public, must-revalidate, proxy-revalidate, max-age=3600	Screenshot

Eine Stunde ist in diesem Zusammenhang ziemlich nutzlos. Es ergibt aber schon Sinn. Wenn 1.4.5 herauskäme, würden alle, die einen /1.4/-Link verwenden und einen einjährigen Ablauf-Header hatten, immer noch 1.4.4 erhalten, und das ist nicht gut.

Latenz, Parallelität und Bandbreite sind immer noch wichtige Faktoren, aber sie verblassen im Vergleich zum Caching. Wenn Ihnen das Caching also sehr wichtig ist, ist die Verlinkung auf eine direkte Version Ihre einzige Option.

Was wählen?

/1.4.4/	Ändert sich nie, also wird er nie etwas kaputt machen. Bestes Caching. Am klarsten zu verstehen.
/1.4/	Möglich, aber unwahrscheinlich, dass er durch zukünftige Updates etwas kaputt macht (Unter-Punkt-Releases sind eher Fehlerbehebungen als API-Änderungen). Ziemlich nutzloses Caching-Level.
/1/	Wahrscheinlicher, dass er durch zukünftige Updates etwas kaputt macht (Punkt-Releases können Dinge ändern). Ziemlich nutzloses Caching-Level.

Ich würde sagen, am besten verwenden Sie in fast allen Szenarien die direkten Version-Links. Die nur-Punkt-Links sind ziemlich nutzlos. Die nur-Versions-Links könnten für persönliche Demos nützlich sein, bei denen Sie möchten, dass Ihre eigene Demo fehlschlägt, damit Sie wissen, wie Sie sie reparieren können.

Skripte kombinieren

Wenn Sie JavaScript-Dateien zu einer einzigen Datei zusammenfassen und so ausliefern können (wie vielleicht dies oder dies), ist es möglicherweise besser, dies zu tun, auch wenn sie von Ihrem eigenen Server oder CDN stammen. Eine Anfrage ist fast immer besser als mehrere.

Nicht nur jQuery

Diese gleiche Namenskonvention / Struktur wird für alle JavaScript-Bibliotheken auf Googles CDN verwendet. Ich habe MooTools getestet und all die gleichen Dinge gelten.

Andere CDNs

Es gibt auch andere CDNs, die jQuery hosten: Microsoft und jQuery.com selbst. Keine davon hat die gleiche Art von Namenskonvention, daher ist das nicht wirklich wichtig. Beachten Sie jedoch, dass ein direkter Link auf dem CDN von Microsoft den schönen einjährigen Cache bietet.

<script src="http://ajax.microsoft.com/ajax/jquery/jquery-1.4.4.min.js"></script>

Die Version von jQuery.com scheint überhaupt keine Caching-Informationen im Header zu senden.

<script src="http://code.jquery.com/jquery-1.4.4.min.js"></script>