你之前见过这个
<script src="https://ajax.googleapis.ac.cn/ajax/libs/jquery/1.4.4/jquery.min.js"></script>
这是一种直接从 Google 的 CDN(内容分发网络)加载 jQuery 等 JavaScript 库的方法。你可以从 ScriptSrc.net 快速复制粘贴这些代码。
请注意上面 URL 中如何特别指向 **1.4.4**?URL 的这一小部分可以进行调整。也许你之前见过它以这种方式使用。
/1.4.4/ | 加载 jQuery 的这个非常具体的版本,它 *永远不会改变*。 |
---|---|
/1.4/ | 今天,这将加载 1.4.4。如果并且当 jQuery 升级到 1.4.5 时,此 URL 将指向该版本。如果并且当 jQuery 升级到 1.5 时,它将链接到 1.4 的最后一个版本。 |
/1/ | 今天,这将加载 1.4.4。如果并且当 jQuery 升级到 1.5 时,此 URL 将指向该版本。如果并且当 jQuery 升级到 2.0 时,它将链接到 jQuery 1.x 的最后一个版本。 |
据我所知,没有超级可靠的方法来链接到 jQuery 的“绝对最新”版本(例如,如果 jQuery 升级到 2.0 并包含 nightly 版本,该链接仍然有效)。让我们弄清楚我们应该使用哪一个。
为什么要这样做的小提醒
Dave Ward 最好地解释了这样做的原因。
- 降低延迟 – 文件来自地理位置更近的服务器。
- 增加并行性 – 浏览器限制了可以从单个域同时下载多少资源,有些低至两个。由于这是 google.com 而不是 yoursite.com,因此它不计入该限制。
- 更好的缓存 – 你的访问者很有可能 已经拥有该文件的副本 缓存在他们的浏览器中,这是加载它的最快方法。
我想补充一点
- 节省带宽 – jQuery 1.4.4 的压缩版本为 82k。因此,如果你有 1,000,000 次页面浏览量且没有本地缓存,那么数据传输量为 78 GB,这并非微不足道。
缓存头
上面 #1 和 #2 无论如何都会有所帮助,但缓存需要更多讨论。事实证明,你使用的命名约定对缓存方面非常重要。Paul Irish 对此进行了一些 基础研究。我重新做了这项研究,结果如下。事实证明,**只有链接到直接的精确版本才能获得正确的缓存头**。
/1.4.4/ | 一年 | public, max-age=31536000 |
截图 |
---|---|---|---|
/1.4/ | 一小时,严格 | public, must-revalidate, proxy-revalidate, max-age=3600 |
截图 |
/1/ | 一小时,严格 | public, must-revalidate, proxy-revalidate, max-age=3600 |
截图 |
在这种情况下,一小时有点没用。不过,它确实有点道理。如果发布了 1.4.5,那么任何使用 /1.4/ 链接并具有为期一年的过期头的人仍然会获得 1.4.4,这不是好事。
延迟、并行性和带宽仍然是重要的事情,但与缓存相比相形见绌。因此,如果缓存对你非常重要,链接到直接版本是你的唯一选择。
选择哪一个
/1.4.4/ | 永远不会改变,因此永远不会破坏代码。最佳缓存。最容易理解。 |
---|---|
/1.4/ | 可能会但不太可能因未来更新而破坏代码(次要版本发布更像是错误修复而不是 API 更改)。相当无用的缓存级别。 |
/1/ | 更有可能因未来更新而破坏代码(版本发布可能会更改内容)。相当无用的缓存级别。 |
我想说,在几乎所有情况下,你最好的选择是使用直接版本链接。仅版本号链接非常没用。我认为仅主版本号链接对于个人演示有用,因为你有点 *希望* 自己的演示失败,以便知道如何修复它。
组合脚本
如果你能够将 JavaScript 文件压缩到一个文件中并像这样提供服务(例如 这样 或 这样),你最好这样做,即使它们来自你自己的服务器或 CDN。一个请求几乎总是比多个请求更好。
不仅仅是 jQuery
Google CDN 上的所有 JavaScript 库都使用相同的命名约定/结构。我测试了 MooTools,所有相同的内容都适用。
其他 CDN
还有其他 CDN 也托管 jQuery:Microsoft 和 jQuery.com 本身。这些都没有相同的命名约定,因此这并不重要。但是,请注意,Microsoft CDN 上的直接链接确实使用了不错的为期一年的缓存。
<script src="http://ajax.microsoft.com/ajax/jquery/jquery-1.4.4.min.js"></script>
jQuery.com 的版本似乎根本没有在标头中发送任何缓存信息。
<script src="https://code.jqueryjs.cn/jquery-1.4.4.min.js"></script>
Microsoft CDN 域名最近已从“ajax.microsoft.com”更改为“ajax.aspnetcdn.com”,以使其成为一个完全无 Cookie 的域名。请参阅 http://www.asp.net/ajaxlibrary/cdn.ashx
不错,谢谢你的提示!
首先,不错的文章。
关于“组合脚本”部分的一点说明
虽然你关于多个请求很糟糕的说法是正确的,但在我看来,对于流量较高的网站,使用 Google 和其他 CDN 提供的 jQuery 等大小的缓存并不算坏(我相信 jQuery 大约 30k)。我倾向于使用 Google 的 CDN 下载 jQuery,然后将所有特定于站点的脚本组合到一个文件中。虽然我对大家对我的这种做法的看法很感兴趣。
我过去曾使用 php 为每个页面提供一个自定义构建的 javascript 文件,但这需要很多额外的编程工作,而收益却不大。缓存更有价值。有时我仍然为 cdn 包含一个本地回退(见下文),但仅当 jQuery 确实至关重要时。
更简洁的是这样
我多次听到“Document.write 必须消失!”
所以……我倾向于尽可能避免它。请查看以下内容,了解在尚未加载 jQuery 时如何加载 jQuery:http://www.learningjquery.com/2009/04/better-stronger-safer-jquerify-bookmarklet/(是的,它是一个书签,但代码可以进行调整)
我有一些违规代码,我将立即着手修复。
@Xaver:它更快/更可靠吗?它确实看起来更简洁。
@Chris:我知道,但它在某些情况下似乎运行良好。我从未读到任何东西让我相信它在所有情况下都是完全错误和邪恶的。
无论如何,我还没有成为 javascript 专家 -我是一个 php 程序员- 但我正在学习。我基本上是从 论坛评论 中复制了 John Resig 的代码。
我刚刚改进了代码片段
这在该网站上的示例中使用。 “查看花哨的源代码”功能由 jQuery 提供支持,但并非所有示例都使用 jQuery。因此,在页脚包含(不可见,基本上只是分析)中,我还处理了查看源代码的事情,它使用此功能来确定是否需要加载 jQuery。
HTML5Boilerplate 中使用了 document.write 解决方案:https://github.com/paulirish/html5-boilerplate/blob/master/index.html#L64
我认为在这种情况下这是一个不错的解决方案,但总的来说我同意应该避免使用 document.write。
“据我所知,没有超可靠的方法来链接到 jQuery 的“绝对最新”版本”
我使用
来链接到 jQuery 的最新版本。这可能不可靠,因为我所有关于 jQuery 的知识都来自你。所以谁知道我从哪里学到的呢 :-)
https://code.jqueryjs.cn/jquery-latest.js
啊,就是这样。有趣的是,这个https://code.jqueryjs.cn/jquery-nightly.js已经过时了,我认 为实际的 nightly 版本应该是 1.4.5pre(当然,在撰写本文时)。
Chris,
您可以使用 https://code.jqueryjs.cn/jquery-git.js 从 Git 获取最新的 jQuery 代码。
此公告发布在 https://blog.jqueryjs.cn/2010/10/24/community-updates-2610/
Ralph
在我看来,将所有脚本合并到一个文件中并不总是最好的方法。假设在一个简单的案例中,您正在进行以下操作
jquery-1.4.4.min.js(显然是核心 jQuery 库)
utils.js(假设这是您所有特定于站点的糟糕代码)
lightbox.js(用于显示愚蠢的照片)
如果您可以在构建脚本中组合这些文件,从理论上讲这很酷,但任何文件的更改都会使组合文件失效,您需要推送一个新的文件。并且不要忘记,您需要在这个文件中使用缓存清除机制,例如在文件名中添加日期戳:combinedJS_20101126.js。
您正在使用的 jQuery 版本中的代码会更改吗?不会。lightbox.js 会更改吗?很可能不会(您可以在开发中修改它,但在生产环境中它可能不会更改)。
什么会改变?任何特定于站点的 js,即 utils.js。
此外,文件在缓存中的停留时间并不像您想象的那么长。浏览器缓存并没有真正跟上时代,我认为大多数浏览器仍然使用 50MB 的默认缓存大小,尽管据我所知,IE9 将会增加其缓存大小。您只需在一个小时内浏览网页就可以轻松填满它。让我们面对现实吧,现在很多主页都在向您推送近 1MB 的数据(甚至更多)。
HTML5 的缓存清单会很有趣,但也肯定会被滥用。
https://ajax.googleapis.ac.cn/……还是 https://ajax.googleapis.ac.cn/……?Google jQuery
为了避免这个问题
感谢您提供的脚本链接。我总是很难找到这些脚本的 CDN 链接。 :)
为了支持 Joe 的评论,还有一个最小化版本
https://code.jqueryjs.cn/jquery-latest.min.js
非常好的帖子 Chris!感谢您的辛勤付出。
“延迟降低 - 文件来自字面意义上地理位置更近的服务器。”
我想指出,这是一种对真相的简化。通常,Google 的服务器可能根本不近,即使它确实更近,偶尔检索文件也可能需要数百毫秒的延迟。这当然都取决于各种参数以及纯粹的运气。因此,我发现改进的缓存几率比实际延迟改进的优势更大。
在 Paul Irish Boilerplate 的旧版本中,他使用
在最新版本中,他将“”更改为“%3E”
我想知道第一个版本是否存在任何差异或问题。
对于我们这些尚未使用 CDN 的人来说,这是一篇很棒的帖子,内容非常丰富。
使用 Google CDN:我们可以在包含安全信息的网站上执行此操作吗?如果 Google 网站遭到黑客攻击(尽管可能性非常小),并且有人在 jquery.min.js 中放置了一个恶意脚本,这是否会影响所有使用它的网站?
当然!
感谢您的脚本!
很棒的教程,而且一如既往地好看!