我非常喜欢这个投票，因为结果非常接近。直到最近一周左右，才出现了一个明显的赢家。
就像本网站历史上所有进行过的投票一样，有很多因素需要考虑，并且这个投票本身可能过于简单了。尽管如此，我认为仅仅让人们开始思考这个问题就是一个成功。从表面上看：20k 更小，但 CDN 更快且更有可能被缓存。
但还有更多内容……
- CDN 可能是一个不同的域名，因此即使用户确实需要加载文件，它也不会计入单个域名的最大并发连接数。
- 加载 JS 是一回事，但执行 JS 是另一回事。执行 200k 的 JS 总是比执行 20k 的 JS 慢。
- Da_n 提醒我们 它们并不相互排斥。您可以尝试从 CDN 加载并回退到本地。
- Evert 提醒我们，某些 IP 地址/范围在某些国家/地区可能会被阻止，因此我们从中提取的不同 IP 地址越多，某些资源被阻止并导致页面加载出现问题的可能性就越高。
- 对于 Google CDN（此类用途中最流行的 CDN），只有当您链接到库的非常特定的版本（例如 1.8.14）时，缓存才会生效。如果您链接的版本不够具体（例如，1.8 会为您提供最新的 1.8.something 版本），则不会被缓存（或缓存时间不长）。
- CDN 可以节省带宽，而这些成本可能非常可观（例如，本网站当前设计中 100k 的图像精灵在过去 30 天内使用了 50 多 GB 的带宽。这只是一个文件）。
- 在本地，您可以选择将 20k 合并到其他 JS 文件中，并加载单个资源而不是多个资源。
- Paul Irish 表示我们应该进行 A/B 测试以确定速度并选择最快的方法。
- 移动设备是一个非常重要的考虑因素。移动浏览器缓存空间更小，并且（有时）带宽更低。
- Kent Davidson 提醒我们，如果我们非常担心隐私，则可能无法使用 CDN，因为它会为每个请求文件的用户向 CDN 提供推荐字符串。
- 在您自己的 CDN 上托管该小型自定义文件具有很大的优势。它可能没有机会被缓存，但具有其他优势。
像这样的帖子让我担心这类投票传播的错误信息……
如果大多数其他开发人员做错了，这并不意味着它是正确的。
仅仅因为“本地”赢得了这次投票，并不意味着它一直都是正确的答案（请参阅上面的注意事项）。
很快就会有新的投票。如果您对 CSS-Tricks 有投票的想法，请在下方留言。我想补充一些投票的想法。
嗨，Chris
您是否考虑过进行一项投票，以了解 jQuery 是否应该与浏览器捆绑在一起？
https://css-tricks.org.cn/13261-large-file-on-cdn-or-small-local/#comment-99489
这更有意义，而且是可行的。
我认为我需要听到一个有说服力的论点。这似乎有点奇怪。例如，页面作者如何指示他们想要“浏览器版本”？或者浏览器是否会劫持对它的请求？以及新版本如何推出？
两个词：“版本控制”。使用 Flash 最头疼的事情（除了使用 Flash 本身）是确保 1. 用户拥有它，以及 2. 他们拥有支持您的 SWF 的最新版本。
我更愿意能够编写版本及其相关的所有内容，而不是依赖于访问者拥有的内容（或不拥有的内容）。
这样的语法会派上用场
if(Bowser.localstorage.frameworks.jquery['1.6.2']) { // The browser ships with a version Browser.loadFramework('jquery','1.6.2'); } else { // We need to fetch our own version fallback = document.createElement('script'); // Create a new script element fallback.async = 1; // Make it load asyncronously fallback.id='jquery-script'; // Let's enable ourselves to reference it fallback.src=('https://ajax.googleapis.ac.cn/ajax/libs/jquery/1.6.2/jquery.js'); s = document.getElementsByTagName('script')[0]; // Get the very first script tag in your HTML s.parentNode.insertBefore(fallback,s); // Insert the fallback } window.onload = function(){ if(!jQuery){ document.getElementById('jquery-script').src='js/jquery/1.6.2/jquery.js'; } };是的，这是一个好主意。
除了某些新功能外，所有现代浏览器都可以拥有一个基本的 jQuery 版本，该版本可以执行几乎 90% 的任务。
它可以极大地提高网站速度。
我们可能会最终看到所有浏览器都实现 jQuery，除了 IE 使用 mootools。哈哈
表面上看起来不错（即使在处理版本控制后——毕竟，浏览器可以想象包含多个最近版本供您的脚本选择），但我最大的担忧是浏览器在选择 JavaScript 库时不应该偏袒一方。
我认为 jQuery 非常棒，但我不会押注它永远都是最好的库。
我一直在使用 jQuery，但我认为人们不应该因为需要/更喜欢浏览器中未包含的其他库而被“抛在后面”（这将是一个合理的风险，因为原生 jQuery 可能会具有如此大的优势，以至于使用其他库的页面看起来很迟缓）。
如果您查看我的实现，您肯定会发现所有流行库都有空间
谁又能说 jQuery 在 5 年后仍然会被使用呢？库针对不同的事物服务于不同的目的，除非 Chrome 或 Firefox 等浏览器需要库特定功能的一部分，否则它将内置到各自的引擎中。除非浏览器需要库才能运行，否则我认为没有必要将专有的 JS 库与浏览器捆绑在一起。
jQuery 非常流行，并且仅核心更新就经历了数百次甚至数千次。由于 JS 库的这种特性，浏览器供应商在每次浏览器更新时都发布最新的 jQuery 源代码并不是一个实用的解决方案。另一个合理的担忧是，依赖浏览器具有正确的库版本是否会导致您的网站崩溃，仅仅因为用户尚未更新其浏览器。
老实说，我认为 jQuery 本身包含在浏览器中并不是一个好主意。首先，这样做会增加浏览器的开销。这种开销对于实现 jQuery 的网站可能无关紧要，但对于那些未使用它的网站来说，这完全是不必要的开销。
其次，浏览器会过时，我们都知道并非每个人都会更新到最新版本，甚至不是最新的最新版本。这意味着 Web 开发人员将需要花费更多时间来添加对旧版浏览器的支持，这些浏览器包含不支持某些最新功能的 jQuery 库。
反对此事的第三个原因是 traq 在上面提到的内容，jQuery 可能不会一直都是最好的 JavaScript 库。
我认为这也不是一个好主意。但是，如果浏览器支持诸如“getElementsBySelector”之类的指令，它将加快 jQuery 中的 DOM 遍历速度（它可以使用它）。我现在没有其他想法，但我认为 W3C 应该考虑新的低级方法来加快当前库的速度。如果我参与此类选择，我会选择这种方式。
http://lievheid.nl/examples/prototyping/document.get.html
请查看我对 document.get() 的实现；它与您期望的类似于 getElementsBySelector 的行为相同。我认为这不是 W3C 应该关注的事情，但您应该向 ECMA 5 开发提出功能请求。
很棒的文章！CDN 可以节省带宽，但您是指成本可能非常可观？我实际上想向您学习 WordPress。我希望看到类似的内容。
我广泛使用过 jQuery 和 Prototype，虽然我发现 jQuery 更用户友好，但我认为 Prototype 在实例化类和面向对象地使用它方面功能更强大。
我通常会从 Google 的 CDN 加载 jQuery 或 Prototype，因为如果用户已经缓存了它们，这可以节省带宽和时间。
网站变化如此之快，并且经常被重新设计/重构，因此当出现这种情况时，必然会出现更快、更稳定的 JS 库新版本。
有趣的是，结果如此接近，并且长时间保持势均力敌。
这变得很有趣。如果他们可以将 jQuery 和其他内容与新版本捆绑在一起，我们就可以真正加快工作流程
这几乎总结了当今网络某些部分需要看到的内容，即使是我也可以从中受益http://www.creativeautomaton.com。
我最近才开始认真考虑将CDN用于除加载JQuery库之外的其他用途。我明白这样做有一些好处，但你的投票结果却令人震惊——这些好处可能值得文件大小差异10倍！你真的让我开始思考了……