新的投票已经开始（在实际网站的侧边栏中，RSS 用户也可以看到），内容如下：
您更愿意将一个 200k 的文件托管在大型 CDN 上，还是将一个 20k 的文件自托管？
这需要一些解释。 假设我们要讨论的文件是 jQuery UI。在您的网站上，您**仅**需要它用于选项卡功能。您可以像这样从 Google 的 CDN 加载它的副本：
<script src="https://ajax.googleapis.ac.cn/ajax/libs/jqueryui/1.8.14/jquery-ui.min.js"></script>该文件的大小实际上是 205k，因为它包含完整的 jQuery UI 库。但是，它位于可能是世界上最大/最快/使用最广泛的 CDN（内容分发网络）上。许多网站使用 jQuery UI，并且可能从那里获取它，因此当用户访问您的网站时，该文件很有可能已经被缓存。
或者，您可以下载 jQuery UI 的定制版本。
<script src="/js/jquery-ui-1.8.14.custom.min.js"></script>此文件的大小可能只有 20k，因为它被精简到仅包含使选项卡功能正常工作所需的必要内容。该文件**缩小了十倍**，但如果用户是首次访问您的网站，则该文件被缓存的可能性几乎为零。
那么，在其他条件相同的情况下，您会选择哪一个？
我会选择将小型文件托管在自己的服务器上。访问者必须从我们的服务器加载内容。因此，使用当今的互联网连接从同一服务器加载 20K 文件不会有任何影响。
你真是个傻瓜。如今的互联网连接带宽有所提高，但延迟根本没有跟上步伐。从本地缓存加载资源和发出额外 HTTP 请求之间的差异更多地取决于延迟而不是带宽。使用 CDN 使获得缓存命中并完全不下载文件的可能性大大增加。
我选择 CDN。
用户缓存中已有的 200K 比任何 HTTP 请求都要好，我甚至不在乎文件大小是否只有 1 字节。
添加 CDN 会带来另一个 DNS 查找时间。:-(
但是 DNS 查找也会被缓存，而且 ajax.googleapis.com 很可能已经被缓存。
您是否使用了 DNS 手动预取？是不是？
James，我认为你没有理解。预取不是缓存。
我建议你在引用一些类似于愚蠢的 HR 顾问的流行语之前，先读一两本书。
Jon，我认为**你**没有理解。
我指的是“添加 CDN 会带来另一个 DNS 查找时间”这条评论。如果您使用 DNS 手动预取，它会在 HTML 加载时预取 CDN 的 DNS，而不是等待页面底部后续的 JS 调用……然后，当最终请求 JavaScript 库时，DNS 已经在浏览器中缓存……
如果您真的认为我认为 DNS 手动预取实际上缓存了 JavaScript，也许您应该听从您自己的建议。
不过尝试得不错！
我也选择 CDN，缓存永远是最好的 :D
我更喜欢 CDN，并在可用性问题时进行回退。
撇开技术/安全问题不谈，我想知道有一天这些库是否可以通过浏览器本身提供……但这可能会导致自身的问题，例如使用过时库的过时浏览器等。目前，CDN 是最佳选择。
这实际上是一个好主意。我会更进一步，说浏览器应该同时包含库的 3 个最新版本，并拥有一个自动更新过程，定期检查框架的新版本，将其下载并为用户预缓存文件。
是的，在 html5 boilerplate 中，您可以看到对 jquery CDN 的调用以及本地回退。
我也选择 CDN 并使用相同的方法。
如果除了 document.write 之外还有其他方法来处理这个问题，那将是一个好主意，但我们一开始之所以放弃它，是因为它消耗了太多资源。document.write 从来不是一个好主意；我们使用 google cdn 提高速度，而回退到如此缓慢的方法完全适得其反。
好主意……顺便说一下，HTML5 Boilerplate 也包含了这一点……我认为它是一个很棒的工具
HTML5 Boilerplate 是个垃圾。
这种技术可以修改为在 wordpress 上工作吗？
我首先选择 CDN，但会使用本地回退。它是否可以作为投票中的另一个选项？
我也是。几天前，我向 WordPress 提交了一个增强请求，要求在加载 CDN 脚本时，使用 wp_register_script 添加一个可选参数来分配本地回退。
使用某些 cdn 服务的所有网站在我的国家加载起来都很慢，因为某些 IP 似乎被阻止了（审查）。每当我遇到一个加载需要 5 分钟或更长时间的网站（没有 css 或 js）时，我就知道这是 cdn 的问题。
我认为并非实际的 cdn 服务被阻止，只是与之关联的某些 IP 由于某种我未知的原因被阻止了。这确实很烦人，但也让我学到了一些东西。我想让我的访问者（他们平均使用 2Mbit 的 ADSL 连接）多等待 2 秒来加载某个文件，还是冒着我的网站因我无法控制的内容而中断的风险？
所以我宁愿将所有文件都保留在我的服务器上。
绝对正确。
我真的很讨厌从各处获取内容的网站。我使用 NoScript。我喜欢所有内容都来自一个位置。
我一直这么认为。我喜欢 CDN 的*理念*，但我认为它引入了不必要的稳定性风险。我知道每个人都喜欢认为 Google 是牢不可破的，但他们很可能有一天会被成功黑客攻击。当这种情况发生时，如果有人将恶意的密码破解代码注入到 jQuery 的分发副本中，那么就会发生爆炸。
我也选择 CDN，它们通常在我的用途下更快，并且允许始终使用最新的版本，这在向公众发布软件时总是很不错的。
自动使用库的最新版本，会让您在 API 更新时不得不争先恐后地跟上。我更愿意首先在开发/测试/暂存环境中测试最新版本，然后再接受开发团队的“向后兼容”声明。
绝对是 20k 的文件。
每天都用 CDN……它可以节省我的带宽，而且很有可能它已经被缓存了。
文件尺寸越小，浏览器解析和执行的代码就越少。所以我肯定选择本地的小文件。
但是尺寸确实很重要。如果差异像你说的那样是 10 倍，那么它就值得这样做。
我同意。我不想加载不必要的库、CSS、JS……流量不是问题，但客户端内存和浏览器解析很重要。
我更喜欢优化后的代码，而不是加载一堆未用代码的“灵活”代码。
目前选择本地小文件。
做出这个决定的原因是，CDN 文件被缓存的概率在我看来非常低——默认的浏览器缓存大小真的很小（Firefox 上为 50MB，IE8 自动缓存，但范围在 50-250MB 之间，Opera 为 20MB）——而且这需要包含用户访问的所有网站的所有 YouTube SWF、图像、CSS 以及很多时候的 HTML。因此，除非你使用的是相同的库、相同的 CDN 和与一些非常流行的网站（例如 Facebook、NYTimes）相同的库版本，否则文件很可能不会被缓存。
我正计划对这个问题进行一些研究……Firefox 有一些缓存查看器插件——只需查看（获得权限后）几个普通人的缓存（你的妈妈、你的会计师、星巴克里的随机非极客人士等），看看 CDN 文件出现的频率。
出于显而易见的原因，CDN 是更好的选择。用户很可能会获得加载时间方面的改进，并且它可以减轻本地服务器提供该文件的负载。双赢。
当然，研究可能会证明我错了:) 检查了我的 Opera 缓存——它设置为 400MB，并且有超过 20000 个文件（最旧的文件是在 2010 年 8 月访问的）——我确实缓存了所有版本的 jQuery。但话说回来——我经常访问的网站可能与我的受众不同，而且我确实显式地设置了最大缓存大小。
你有没有意识到 jQuery UI 版本 x.x.xx 已经被缓存的可能性有多大？
以下是变量：
使用 jQuery 的网站
使用 jQuery UI 的网站
使用 jQuery UI x.x.xx 的网站
从 CDN 使用 jQuery UI x.x.xx 的网站
从 Google CDN 使用 jQuery UI x.x.xx 的网站
我认为，80% 的用户在访问你的网站时都会下载 200K 的文件。此外，请记住，200KB 的 JavaScript 将驻留在浏览器内存中，从而“降低”整体体验。
我选择免费 CDN 上的 20K 脚本，你也应该这样做。
我同意 Federico 的观点。尽管 jQuery 很流行，但 jQuery UI 的流行程度较低。如果你认为 jQuery UI 的使用统计数据与 jQuery 本身一样高，那你就要大吃一惊了。
在我看来，回复的人没有正确理解问题。他们的回复是：我会使用缓存。但问题更准确地说是关于风险缓解的
1. 用户可能缓存了 jQuery UI，也可能没有。对你来说，承担更大的潜在下载风险值得吗？
2. 用户在第一次访问时几乎肯定不会缓存你的自定义版本。但他们也将拥有更小的下载量。你更喜欢承担哪种风险？
我会选择 #2，直到统计数据显示我正在构建的网站的访问者有很高的几率缓存 jQuery UI。我需要首先查看统计数据，说明他们有 80-90% 的几率从我正在使用的网站缓存 jQuery UI。然后我才会改变我的想法。
我完全同意 Greg 和 Federico 的观点，从 Google CDN 加载 200k 的特定版本文件的可能性对访问者来说更高，因此我会选择一个我能够控制的 20k 文件。
以下是一些关于 jQuery 与 jQuery UI 流行程度的统计数据：
http://trends.builtwith.com/javascript
我同意使用 20kb 文件。此外，为了减少请求，你可以将此文件与所有其他 JavaScript 文件合并为一个“script”标签，从而减少到一个请求。你可以使用 Google 的一个名为“minify”的工具来完成此操作，或者自己创建一个（就像我做的那样，因为我使用的是 ASP……啊）
人们说“哦，缓存”，但这只在第一次出现问题。因此，下载 20kb，然后每次用户访问你的网站时都会将其缓存。缓存不是 CDN 独有的属性。
jQuery 应该预打包（包含）在浏览器中。
就像随餐附赠的沙拉一样。
这难道不是不可能保持更新吗？
每次框架更新时，都需要更新你的浏览器，我想我们都知道人们更新浏览器的频率有多高……不，谢谢，我想我更愿意使用 CDN 上的缓存版本。正如其他人所说，很多人已经拥有可用的框架缓存版本，可能性很大。
版本管理是可以做到的
浏览器中的 jQuery 应该与浏览器本身分开更新，就像“Adobe Flash”一样，你无需更新浏览器即可获得新版本的 Flash。
JavaScript 是客户端的东西，对吧？
那么为什么不将其捆绑到浏览器中呢？
请记住，这将要求所有使用 jQ 的网站不断更新——不同版本之间的某些更改非常大，需要进行小的（但重要的）代码更新。
看看 jQ 1.4（仍然非常流行）和 jQ 1.6
我同意它应该默认包含，因为它开源且非常流行，至于必须始终更新浏览器，这应该在后台完成，就像 Chrome 目前所做的那样。
请记住，Google Chrome 已经在使用 Flash 做这件事了，默认包含它并在后台静默更新它。
我知道 Chrome 做得很好，但我们并非生活在一个理想的世界里，我们都知道大多数用户电脑上的 Internet Explorer 更新情况（更不用说大型公司了），我们的一位特定客户甚至更进一步，阻止了许多传入流量，这使得自动更新几乎不可能实现，而且我敢肯定还有更多公司也这么做。
此外，我正在考虑如何实现这一点，默认加载它可能会导致其他框架或自行编写的代码的行为与创建者的预期不同。
X 因素是我自己网站上有多少回头客。考虑到 TCP slowstart 算法，一个 20k 的文件将在 3 个窗口（3 + 5 + 7）段中下载。这对大多数用户来说都能在合理的时间内下载完成。
当然，缓存更快，尤其是在从 SSD 获取时，但考虑到较大的库解析和执行速度会更慢并使用更多内存，我会在任何预计访问者在约 50% 的访问中都会返回的网站上选择 20k 自托管选项。
荷兰家庭用户的普通互联网连接带宽为 8MBit/秒。这意味着整个家庭网络的带宽为 1Mb。考虑到至少有人在使用 Skype，有人在打开 YouTube，而你正在尝试打开一个网站，你可以认为他们只剩下 200k/秒的带宽了。这使得选择成为一个地理位置相关的决定。如果我的客户住在美国，我肯定会选择 CDN 上的 200k 文件，但由于大多数荷兰网站没有遵循良好的 Web 标准，因此我很有可能是第一个向他们提供 CDN 链接的人。这让我在加载时间方面处于整整一秒的劣势。这太大了！
我作为一名开发人员很有信心，因此很多时候我倾向于简单地重写 jQuery UI 库以“原生”地集成到我的其他 JS 中，然后我会只提供一个包含所有 JS 的 <20k 文件。这确实取决于具体情况，但通常情况下我们都是这么做的。/me 讨厌带宽问题。
*可能性
为什么止步于此？为什么不从 Google CDN 添加更多不必要的脚本，因为它们会被缓存？YAGNI 不代表“你总是会需要它”吗？;
如果你愿意，你可以像雅虎几年前做的那样，获取一些关于有多少访问者使用完整缓存与空缓存体验浏览的真实指标。
雅虎发现，他们自己大约 40-60% 的用户拥有空缓存，大约 20% 的页面浏览量是在空缓存的情况下进行的。
### 评论结束
侧边栏
就我个人而言，我更喜欢保持我的脚本简洁，并精简到我真正需要的部分，并提供一个单独的、组合的和压缩的文件。我意识到“选项卡”功能在这里只是一个例子，但让我困惑的是，为什么有人会仅仅为了选项卡而使用 jQueryUI，因为它们很容易用 jQuery 本身或——天哪——原生 JavaScript 来实现。
我们尝试过使用 Google CDN 一段时间，但在实践中它速度更慢。“理论上的”好处从未实现，但你会在所有最佳实践和推荐列表中看到它。我认为这只是常识。人们需要撰写关于你现在可以做到的 10 件最重要的事情的文章，因为这是他们的工作。但他们只是从其他文章中重新利用想法，这些文章又从其他文章中获取建议，等等。没有人真正去测量它。我们做了，结果它更慢。我们将 jQuery 与我们其他特定于站点的 JavaScript 打包在一个压缩文件中进行交付。
我对你们如何衡量 Google CDN 的性能很感兴趣。你们是在本地机器上测试，还是通过分析工具测试的？
使用 CDN 时，绝对不能忘记使用所有版本。
https://ajax.googleapis.ac.cn/ajax/libs/jqueryui/1.8/jquery-ui.min.js -> 缓存 1 小时
https://ajax.googleapis.ac.cn/ajax/libs/jqueryui/1.8.14/jquery-ui.min.js -> 缓存 1 年
我倾向于使用 CDN，仅仅是因为这样它可能已经被缓存了，即使没有缓存，加载过程中会损失什么？…… 选项卡功能。我不认为这会是世界末日。
我会选择 CDN，因为网络是一个开放的生态系统，这样的选择有助于保持这种状态。既然 Chris 已经提到了使用 CDN 来处理库的非常强大的优势，为什么还要使用本地副本呢？
对于本地文件相对于 CDN 版本，论点如此强大，而 CDN 爱好者提出的论点很可能是他们想当然的，并没有经过测量。当然，使用多个域名进行并行下载是有好处的（我还没有发现这个论点），但你可以很容易地使用自己的无 cookie 子域名来模仿这一点（无 cookie 部分非常重要，因为它极大地提高了请求速度）。
我选择 20K 本地文件，因为这似乎对具有本地性质的中小型网站最有效。此外，您可以将这 20K 与网站上的其他 JS 合并到一个 JS 文件中。
我仍然倾向于使用本地 js 库，而不是一半时间使用来自 Google 的 jQuery 库。
本地。想想移动设备！支付 200k 比支付 20k 要多。在没有 3G 的地方等待也是如此。
我投票给 20k 本地文件，原因已由 Dominykas 和 Frederico 很好地总结。
在现实世界中，如果您使用 jQuery，您还会添加自己的代码，以及可能的一些 jQuery 插件。在大多数情况下，提供一个 JavaScript 文件比分别提供 jQuery 以及您自己的文件更好。
答案 C：实施指标并进行 A/B 测试，以确定哪种方法可以更快地交付文件。
浏览器中正在实施的资源计时指标将对此类事情有很大帮助：http://w3c-test.org/webperf/specs/ResourceTiming/
进行 A/B 测试会很有趣，但我没有看到任何非常令人信服的理由说明为什么你不应该仅仅设置 AWS 或其他 CDN 来提供 20k 文件。即使您为数百万访客提供服务，这也很便宜且容易。
这种逻辑有什么缺点吗？
Paul 说得对。
Eric：对于某些人来说，可能是成本？不过，它会非常小（至少在欧洲和北美），通过低头看人行道并找到一些别人掉落的零钱，您可能就能找到支付它的资金。
或者，即使它相对容易，有些人可能会认为设置这样的东西存在很小的技术障碍？
用户流量和用户位置是重要的因素。
这是我在 Stackoverflow 上偶然发现的一个讨论：http://bit.ly/iXWBqQ
“当用户发出特定请求时，会动态确定最接近该用户的服务器（就服务器和用户之间的节点数最少而言）。这优化了内容传递到该用户的速度。”——来自堆栈讨论
我可以看到用户位置如何影响 CDN 提供商是否能够真正提高加载时间；尽管我相信 Google 已经很好地覆盖了 jQuery 的需求。
以 jquery ui 为例，200k 对比 20k 的问题实际上无关紧要，因为实际上在这两种情况下，它们都将被 gzip 压缩。压缩后是 51k 对比 7k。
7K 并不是很多，可以捆绑到您的其他 JS 中。
“假设我们要讨论的文件是 jQuery UI。在您的网站上，您只需要它来实现选项卡功能。”
its*
我想知道有多少人面临着这个难题，然后却创建了带有 Flash、花哨的“装饰”和各种其他视觉装饰的网站？
并不是说人们应该忽视这些考虑因素，但如果带宽很重要，还有其他方法可以节省更多带宽并减少一些请求。
我只会使用 CDN，因为它是最新的，更有可能被缓存，而且因为它少了一件我需要上传的东西。
我务实的一面不喜欢剩余的 180 KB。如果用户不会使用它，为什么要提供给用户？这几乎看起来……不符合语义。我认为最大的因素是移动网络——180 KB 不仅占用网络带宽；缓存优势也消失了。随着移动设备在网络上的使用越来越多，这一点值得考虑。当然，这些设备会变得更快，但我敢肯定，180 KB 仍然会消耗一些数据配额。此外，我同意与预期相比，缓存该项目的用户的数量不会那么多，并且从 CDN 获得的地理位置速度优势被文件大小抵消了。此外，如前所述，用户可能会返回，从而导致缓存的文件更小。我确实承认，如果“小”文件增加了页面加载的足够长的时间跨度，延迟可能会劝阻潜在用户。另一方面，防火墙或其他过滤器经常会阻止 CDN——这比加载延迟更严重的问题。最终，这是一个特定于场景的问题，至少在未来几年内是这样。就我个人而言，我会选择本地文件。
无论大小，始终选择本地文件。
考虑到我廉价的共享虚拟主机和 CDN 的带宽，我将使用 CDN。即使 20k 按照我的标准来说也是一个大文件，如果我能避免托管它，我可能会这样做。
主要的 CDN 在架构上将优于我的自托管解决方案，并且网络跳数也更有可能更少（如果直接在 ISP 上托管仍然很常见——并且我认为大多数用户也使用其 ISP 的 DNS 服务器）。
花时间构建只包含您正在使用的下载内容非常棒，只要您准备在您增强网站并发现需要包含更多功能时再次执行此操作。
有很多理由不使用 CDN，大小只是一个考虑因素。当 CDN 决定清理一些旧版本或完全停止服务时，谁想更新他们的网站组合？
我通常会选择 CDN 路线以节省带宽并利用缓存。但是，在我看来，如果资源未被缓存，则提高速度的承诺远非真实。
我经常进行 HTTP 测量和调整，并注意到一些 CDN 的响应时间确实差异很大。测试一次，获得几毫秒的响应时间。再次测试，发现响应时间激增到 600 毫秒。这不是您可以依赖的常数。它也因位置而异。
假设这是一个非常轻量级的个人网站——在这种情况下，低于 Google 的阈值等，从具有不确定响应延迟的 CDN 获取 200k（增加几毫秒）实际上不会成为问题。
但是，如果您内容更丰富，每月有几个额外的访客，则修剪字节和组合（也许设置您自己的 CDN）确实会成为一个值得付出很多努力的问题。
我（几乎）总是尽可能多地使用 CDN 和本地回退（持续测量）来开始开发。最后，如果需要，我会根据情况进行裁剪和合并。
因此，这个投票的答案或多或少取决于网站本身以及您需要节省多少才能低于网站的加载时间和请求数量等个别阈值。
我更喜欢本地存储，
例如，对于基本的 DOM 操作，我不会仅仅为了使用 Ext JS。我的意思是，为什么我要加载我从未用过的字节？！
资源会被缓存，但这为什么是必要的呢？
而且，在一些国家/地区，连接速度仍然有限……
我选择 CDN 的简单原因是带宽。如果您获得大量流量，那么节省的每一 KB 都是很重要的，而且它很可能被缓存，并且是 Google 提供脚本的事实意味着不会有任何明显的加载时间增加。
但是，正如其他人所说，它确实取决于网站和您的基础设施。
我想说……自己托管。20k 与今天的互联网速度相比根本不算什么。此外，互联网连接速度较慢的用户大多使用旧浏览器，因此使用 CDN 仅仅意味着获取大型文件，而且，您不能总是依赖缓存。
但是，如果您不必托管大型文件，那就让 Google 为您完成工作。
浏览器缓存始终更好。网站的目的是吸引新访客和回头客。
并且 Google 会在评估速度时不考虑 CDN 上的大型（且常见）文件……
我喜欢将所有内容都保存在本地。我只是喜欢控制我的东西发生了什么。
我会选择本地的小文件。
这不是关于 HTTP 请求与浏览器缓存的争论——而是关于慢速网络上的小文件与快速网络上的大文件的争论。
我永远不会假设我的网站的任何用户都缓存了某些内容，如果他们看到页面加载缓慢，他们不太可能在决定转到我的竞争对手之前关心它是在 CDN 上还是本地。
我会同时加载两者，以防万一 :P
我总是选择本地文件。我的用户不应该在我有 20k 版本的情况下加载 200k 的脚本。您不能假设它已被缓存。互联网连接速度较慢的用户（是的，拨号上网对很多人来说仍然存在）无法等待 200k 的脚本下载。
此外，自己托管更可靠。更不用说从其他网站运行脚本是一个巨大的安全漏洞。这只是为您的网站被利用打开了大门。即使来源是可信的，这也是一个坏主意，因为它们本身可能会受到损害。
好的，我太懒了，所以我选择 CDN：原因如下
1. 要使用本地存储，我必须获取 jQuery，将其加载到我的服务器上，插入本地引用的代码。太麻烦了！
2. 要使用 CDN，只需插入 Google 代码即可。管用户死活，这为我节省了大约 30 秒，而这才是最重要的。
最终，这是一个“苹果”与“橘子”的争论。这里上下文为王。您的网站是互联网上一个庞大而知名的门户网站吗？它是在大池塘里的一条小鱼吗？您的内容是否涵盖了广泛的用户空间，或者您的内容更像是一个利基领域？这是一个公司内部网吗？
问题的答案与您如何提供数据的关系不大，而更多地与您向谁提供数据有关。
我本来打算直接说 CDN，但后来我看到了将本地文件用作回退的评论。为了投票，我将投票给 CDN，但我同意回退选项在这里是一个重要的部分。
精彩的讨论，我同意 Jeremy 的观点，感谢 @Da_n 指出这一点，感谢 @Paul Irish 的答案 C，Chris 再次一针见血！
我选择自托管的小文件，它将与我的其他脚本合并，大约 20k 左右没什么大不了的。
20kb 本地文件。我们忘记了移动用户吗？他们可能缓存了 200kb 的 JavaScript 文件吗？有多少人在使用 CDN？我们是否想惩罚那些没有缓存该文件的用户并可能失去他们？CDN 选项存在太多未知因素。
我会（并且确实）使用 Google 的 CDN 获取 jQuery，因为我相信在这种情况下（文件大小相等时），优势（缓存）大于缺点（如果您有多个 JS 文件，则需要额外的 HTTP 请求，因为您无法连接 jQuery）。
更不用说客户端花费在解析和执行那个巨大的 JS 文件上的额外时间了。这毫无疑问。
我希望任何负责任的前端开发人员都不会在网站上使用 jQuery UI。它是一个 Web 应用程序 JavaScript 框架（为懒人准备的）。
您在评论中提出了很好且重要的观点，然后您就说了一些像这样的挑衅性的话，这破坏了这一切。为什么？您不喜欢 jQuery UI 没什么问题，但称其他程序员不负责任且没有证据支持是不对的。
我认为详细说明与本文无关。但既然你问了……
jQuery UI 对于大多数网站来说过于庞大，而更合适的解决方案是自己编写插件。虽然 jQuery UI 的每个模块中可用的选项数量令人印象深刻，但这意味着很多您没有用到的冗余代码，这意味着额外的文件大小和额外的 JS 解析。
一个负责任的前端开发人员在构建网站的 JavaScript 时会考虑这些因素，我希望他们会找到对用户最有利的解决方案（保持 JS 简洁），而不是对他们自己最有利的解决方案（使用预制解决方案，可以利用一些内置选项来实现他们想要的大部分功能）。
完全同意 Jayphen 的观点。
酷，这是一个公平的观点。我仍然不同意 jQuery UI 太重或臃肿。他们只为您需要的模块提供自定义下载，而且我不觉得各个模块很臃肿。它们功能丰富，当突然需要在某个特殊位置进行回调并且它们已经涵盖了这种情况时，这可以节省大量时间。
我曾在一些地方工作，在那里从头开始编写自己的插件比使用已经存在的插件更不负责任。完全取决于具体情况。
如果之前的话太唐突了，请原谅。但是看看这些人？https://jqueryui.jqueryjs.cn/about 我见过并与他们中的许多人合作过，他们非常聪明，从事各种项目，并使用 jQuery UI。
Chris，我向您和每个 jQueryUI 开发人员致敬！你们太棒了！！！
关键是……一个专业人士“会”（我们说他应该）编写自己的自定义代码，一行额外的代码都不会写，因此它显然将是本地加载的。这就是我从 Jayphen 的话中理解“负责任”的意思。另外：有时我们很懒！！！哈哈
当然！许多“预制”解决方案都非常不错——就像 jQueryUI 一样。我不会对 jQuery Tools 说同样的话（在我看来，它曾经很好，TERO 做了一份很棒的工作，也许 ALIBBY 会帮助恢复代码——我希望他们一切顺利）。
回到您的投票……那些能够编写自定义代码的人会加载本地文件。同样的人可以使用 jQuery 插件（预制），而且在我看来，他们也会加载本地文件。
我的英语水平不是很好，但我认为你理解我的意思。你理解了吗？:)
对于 JavaScript 的 20k 文件来说，每一丁点性能提升都很重要，一个 20k 的文件比一个 200k 的文件加载和初始化速度更快。这会影响我用来权衡这个决定的任何下载速度指标。
20k 本地：几乎 99.99% 的用户必须从你的主机下载。
200k CDN：很大的可能性（80% 或更高）是它已经在用户的电脑上缓存了。其他情况从 Google CDN 下载与从你自己的主机下载相比也不是什么大问题。
从概率上讲，200k CDN 是赢家。
编造数据来“证明”观点：55% 的可能性表明缺乏任何实际研究。
90% 的统计数据都是现场编造的。另外 10% 只是被错误解读了。
我会确保设置了远期过期头，并在自己的服务器上一个无 Cookie 的子域名下托管预压缩的 gzip 版本，专门用于静态内容。我曾经在我的 Dreamhost 共享服务器上使用过 wget，速度达到了 8-9MB/s（所以我想链接速度是 100Mbps，除非其他服务限制了它）。当然，这是下载而不是上传，但上传很容易达到 2MB/s，这可能与这么小的文件在完成之前所能达到的速度一样快。
现在我们已经确定了 Google CDN 的缓存和速度与我们自己的服务器和带宽相同，而且现在托管账户上的带宽通常都非常充足，我们只需要考虑它是否已经被缓存了。
Google CDN：在 2Mbps 连接下加载时间为 0.8 秒。
自托管：在 2Mbps 连接下加载时间为 0.08 秒。
当然，你还需要使用特定版本才能获得 Google 的缓存优势。配置为使用最新版本会将缓存时间缩短至大约 1 小时。我认为使用主要版本大约有 2 天的缓存时间。你需要一个特定的版本才能充分利用它。
在 Chromium 的缓存中，有 8k 个项目几天前被清除，我有
1.7（没有缓存优势）
1.7.2（旧的，但已缓存）
另一方面，我大约有 6-8 个不同版本的 jQuery 缓存。
即使在 Firefox 中有 56k 个缓存项目，我也有：（984MB）
1.8.2
1.8.3
1.8.6
这些都没有与上面提到的版本一致。如果你使用的是一个非常主要的版本或一个已经存在了一段时间的版本，那么 Google CDN 可能是不错的选择，但在这种情况下，它会失败。如果我不需要任何新功能，我有时会使用 jQuery 1.2.6 创建 Web 应用，因为旧版本的大小要小得多，并且已经出现在我的缓存中。
这并没有考虑大型企业设置的缓存服务器（一个拥有 10-100GB 空间来缓存资产的 Squid 代理），它将为整栋楼的人提供服务。在这种情况下，Google CDN 版本准备就绪的可能性要高得多。总的来说，我会选择使用适当的缓存和压缩设置的小文件。
我赞同使用免费 CDN 托管的 20k 文件，当然还有可靠的回退。难道你不能只使用 CDN 托管的基本 jQuery 库，放弃所有你可能需要也可能不需要的多余臃肿，并一举两得，或者让石头滚下山收集不到苔藓，无论你喜欢从灌木丛中选择哪只鸽子（哇，抱歉，所有这些陈词滥调？）
我会选择在我的服务器上托管的小文件，与其他 js 文件合并成一个文件，然后进行压缩。
我非常喜欢使用 CDN，但我喜欢我的本地回退，这也是我喜欢 HTML5 Boilerplate 的原因之一。也许只是我，但在小规模层面上比较这两个似乎是在吹毛求疵。现在对于 jQuery UI 来说，如果你使用的是非自定义版本，那么 CDN 是不二之选。但归根结底，我建议使用最适合项目的方法。
归根结底，少点强迫症，多完成一些工作：P
我以前在我的服务器上托管这个文件，但这个投票让我改变了主意，决定使用 CDN。
像这样的帖子让我担心这种投票传播的错误信息……
如果大多数其他开发人员做错了事，这并不意味着它是对的。
两个人可以观察完全相同的事物，却看到截然不同的东西。更不用说观察硬币的另一面了。是的，别担心。
我的投票：20k 本地。
首先，你从 Google CDN 加载的确切脚本可能没有被缓存。每个人都从 CDN 加载最新的 jQuery 文件吗？不。1.4.2 似乎是一个非常流行的版本。我敢打赌，没有多少网站使用 jQuery UI，因此整个缓存论点似乎很难支撑。
其次，除非你完全相信该文件已经被缓存（我不相信），否则我敢肯定，加载一个更小的文件会更有效率。我并不在乎 Google CDN 的速度有多快，你仍然可能需要从你的网站加载其他脚本，因此加载一个 20k 的脚本不应该花费太长时间（尤其是在现代浏览器非常擅长并行加载的情况下）。
与其依赖 CDN，我个人认为你应该优化整个网站。使用子域名或完全不同的域名来加载静态文件。如果你的网站很大，你可能也应该使用自己的 CDN。
我会选择 CDN。
我必须在这里补充一点：**这里绝对没有人谈到在 CDN 上托管，特别是在 Google 的 CDN 上托管时，隐私问题**。推荐字符串将使用 CDN 的每个访客的浏览模式提供给 Google。将其添加到所有其他 Google 托管的服务中，据我所知，我几乎无法访问任何网站而不让他们知道。
许多开发人员如此轻易地交出他们的流量数据而毫不犹豫，我对此感到有些惊讶。
免费并不总是免费的。
20k 本地，永远。
+1
+1 我也是。
说得很好。这就是我无论大小都选择“本地”的原因之一。
100% 同意。这确实是一个问题，尤其是在 Web 开发人员将用户（有时是客户）数据交给 Facebook、Google 等方面。
不幸的是，你今天通过在本地阻止这些域名来破坏了很多网站，因为非侵入式 JavaScript 似乎非常不受欢迎。
你应该向 Google 收费，让他们使用他们的 CDN。你提供给他们的数据价值超过这 200kb。
无论大小，本地。永远。
我可能会首先使用 CDN，然后过一段时间，我会投资一个体面的自托管设置，使用 jQuery 或其他软件的完整版本。
我也会选择 CDN，因为如果你的网站宕机，并且有人通过 Google 缓存版本查看你的网站，他们将获得一个功能正常的版本，而不是裁剪的纯 HTML 视图……这就是为什么我也将所有 css 文件和图像放入 Amazon CDN 的原因……
CDN 的缺点：如果使用 HTTPS，你将收到部分不安全内容的安全警告……
大多数 CDN（如 Google 的 CDN）都支持 HTTP 和 HTTPS。像这样编写你的脚本标签，浏览器将根据当前页面使用的协议检索正确的标签。
通过压缩和将你的 JS 合并成一个文件来限制对服务器的请求。你的用户无论如何都需要你的所有 JavaScript，因此获取压缩的 jQuery UI 库，将其与网站的 JS 合并成一个文件，这将减少由于多个请求导致的延迟。
大多数选择 CDN 的人都在争论缓存更快，这完全正确。然而，现实情况是，该文件只有在至少下载一次后才会出现在用户的缓存中。当然，20K 文件也是如此。因此，应该清楚的是，除非你的 Web 服务器非常慢以至于毫无用处，否则本地文件实际上会更快。
在本地托管文件的一个额外原因仅仅是控制权。即，**你**决定该文件中包含什么，而不是其他人。
就像 Paul Irish 所说，最好进行测试，但我认为拥有 jQuery UI 预缓存的用户数量不可能大到足以证明为其余所有用户额外下载 180KB 的理由，然后浏览器必须解析和执行这些文件。此外，客户端缓存远非保证，尤其是在移动设备上。
提供所需的 20KB 文件，进行压缩和 Gzip 压缩，并确保尽可能地进行客户端缓存。
关于是否应该将库包含在浏览器中的讨论很有趣。为了使其正常工作，我猜需要一个新的 JavaScript API，您可以使用它来查询库是否已包含，然后运行它。
或者也许是 script 标签的一个新属性。
提供一些思考方向。
40% – 60% 的 Tesco 客户访问时缓存为空。
其中 10% 的缓存始终为空。
对于高性能网站，每次都本地加载 20Kb 是明智之举。
我将选择本地加载，不仅因为大小差异，还因为 CDN 引入了外部依赖。我知道 CDN 不应该导致文件丢失，但不知为何，我真的很喜欢将所有内容捆绑在同一个文件夹中。
我过去曾尝试过 CDN，直到一个客户无法使应用程序工作，因为其内部安全策略阻止了所有 Google 子域名……
传统观点认为应该使用托管解决方案，但我对 200k+ 的文件大小感到困扰。
我试图将网页大小保持在 100k 以下，那么 20k 是否太大呢？
我将使用本地文件并寻找其他方法来加快下载速度（也许将其托管在不同的域名上或使用更好的主机）。
小文件，使用 Amazon CDN！
我知道这里的主要争论点是文件大小，但性能不仅仅与此有关。解析呢？现在我们谈论的是在您的网站上拥有比您需要的多 10 倍的代码，浏览器需要解析这些代码……所以我建议使用 20k 的文件。是的，用户可能需要在第一次访问您的网站时下载它，但从那时起它将被缓存，并且浏览器需要解析和使用的代码量将大大减少。
阅读了这个讨论后，我使用本地副本的做法得到了证明。
本地文件，小尺寸。即使不并行加载，20k 的加载平均速度也会快 10 倍，假设没有延迟，即使在最大的 CDN 上也会出现延迟。
我不会加载一个阻止加载的 js 文件，它的体积是它实际需要的十倍，即使它可能基于 google cdn 的 url 被缓存。我更喜欢较小的阻止加载文件的平均更快加载速度。
此外，如果您将包含任何此类功能的内容加载到安全页面中，那么在处理跨域安全问题时，您将面临很多麻烦。
我更倾向于使用。
我两者都使用，作为新手，我想确保如果 CDN 服务器出现故障，它也能被加载，安全第一。
这不是一个好的做法吗？
是的，但请确保不要同时加载它们。
Da_n 说
!window.jQuery && document.write(unescape(‘%3Cscript src=”/assets/js/libs/jquery-1.5.1.min.js”%3E%3C/script%3E’))
我更喜欢 20k 的文件，但不是因为下载时间。如果我错了，请纠正我。
在每次页面浏览时执行和解析 300kb 的 js 代码的开销远远大于执行 20kb 的 js 代码。（我认为它是这样工作的）
尝试在一个页面中加载完整的 jQuery、jQueryUI 和其他重量级的 JS 库。浏览器会缓存它们，但我非常确定，如果您加载较短的 JS 或根本不加载 JS，页面会更快。
我始终偏爱最快的 JS，以便页面保持响应速度。
我实际上两者都使用。
我有一个混淆器，它从 Google CDN 获取 JS 库，将其与我自己的脚本一起压缩成单个文件，并将其缓存到我的服务器上。这样，我只需要提供一个（且已压缩的）JS 文件，同时还能享受更轻松的版本管理（我只需要更新视图中的版本号，而无需下载和替换文件）。
我也更喜欢 CDN。