了解为什么出于安全考虑、网络惩罚和避免单点故障，将 JavaScript 托管在内容交付网络 (CDN) 上不再是最佳实践。

长期以来，在 CDN 上托管静态文件是性能调整网站页面的事实标准。该主机提供了浏览器缓存优势、更好的稳定性以及跨战略地理位置的快速边缘服务器上的存储。它不仅具有性能优势，而且对开发人员也很方便。然而，最近的发展表明，自托管静态文件，如 Ajax（异步 JavaScript 和 XML）和 jQuery 库、CSS 样式和其他包含指令更快、更可靠，并且为系统增加了更好的安全性。

CDN 使用可能导致性能下降

大多数开发人员和管理员认为添加 CDN 托管的静态文件可以提高性能。想法是 CDN 拥有快速的边缘服务器，可以缓存内容并根据用户的地理位置进行交付。这些缓存服务器比传统的单一托管服务器更快，并且开发人员获得了便利。

然而，一些研究表明，在第三方服务器上托管静态文件（例如用于启用 Ajax 功能的 JavaScript、CSS 和 HTML 文件）时，实际上可能会降低性能，尤其是在引入 HTTP/2 时。在CSS Wizardry 的 Harry Roberts 的这项研究中，他强调了他所咨询的一家公司如何能够在将静态文件从第三方服务器移动到自托管解决方案后将延迟减少 300 毫秒。节省的 300 对销售和收入产生了直接影响，使公司的底线增加了 800 万英镑（合 11,000,000 美元）。

同一项研究还表明，较慢的移动连接会因在第三方服务器上加载文件而经历更高的延迟。在 3G 上，与自托管文件相比，同一客户的客户经历了 1.765 秒的减速。将文件迁移到本地服务器后，客户端的加载时间从 5.4 秒变为 3.6 秒。

这可能看起来不是一个可观的数量，但考虑到每天有数百万用户访问的大型企业网站，每月很容易加起来数亿。在规模上，延迟问题会迅速渗透到最终用户体验中。网站的速度已显示会影响跳出率、客户满意度和客户保留率，更不用说谷歌将网站速度纳入其排名算法的方式了。

避免单点故障

如果您曾经经历过灾难恢复练习，您就会知道冗余是抵御故障的弹性的关键。如果这些第三方服务器出现故障，内部基础架构也会出现故障，除非您配置了故障转移系统。流行的第三方 CDN 和云服务已将故障转移融入其基础架构，但正如我们最近看到的那样，即使是最大的云提供商偶尔也会出现中断。

一种观点认为，云中的服务很少（如果有的话）失败，但即使是最大的提供商也会发生这种情况。例如，早在 2017 年，一个简单的操作错误导致整个弗吉尼亚州美国东部数据中心区域的 AWS S3 存储桶崩溃。S3 存储桶用作云存储，停机时间影响了数千名 AWS 客户。那些没有配置故障转移且仅依赖 AWS 的企业肯定会经历停机。

使用第三方提供商托管静态文件（例如支持 Ajax 功能的 JavaScript、HTML 和 CSS 文件）也会使业务面临同样的中断。可以为故障转移编写代码，但许多中小型企业没有这些资源可用。停机时间可能会造成数千美元的收入损失，因此它应该始终是一个值得关注的问题。

一个小但相关的风险是第三方主机退出服务。这在 AWS、GCP 或 Azure 等大型组织中很少见，但较小的托管商可能随时关闭服务，使站点应用程序所有者难以尽快找到替代方案。

网络惩罚如何影响性能

与第三方主机相关的网络惩罚与性能下降有关，但它们可以更深入地了解它发生的原因。对于加载期间包含的每个新源，浏览器都会打开一个新的 TCP 连接。某些网站在 Web 应用程序中包含多个外部脚本的情况并不少见。

此外，大多数站点现在都在使用 SSL/TLS，因此客户端和主机之间需要握手，以确定将用于加密数据和传输用于建立会话的对称密钥的密码。如果您有几十个第三方文件，这会迅速增加加载时间的延迟。作为一种解决方法，您可以使用预连接资源提示向浏览器指示您希望尽快处理连接和文件下载，从而最大限度地减少从第三方域打开文件的影响。

第二个损失是 HTTP/2 中可用的优先级丢失，这是大多数应用程序当前使用的。HTTP/2 协议提供了连接优先级的功能。优先级允许开发人员定义重要的连接，以便可以更快地返回关键文件并延迟加载不太重要的内容。

连接优先级在同一域上运行良好，但必须为每个为外部文件创建的新外部 TCP 连接构建依赖关系树。这意味着当多个第三方域用于托管文件时，您无法构建一个依赖树，这会增加延迟。请注意，可以使用 连接合并来克服此限制，但域必须解析为相同的 IP 地址，并且每个浏览器都以不同的方式处理它。

考虑安全考虑

对于关键应用程序，在第三方服务器上托管静态 JavaScript、HTML 和 CSS 文件（以支持 Ajax 功能）会增加网络安全风险。如果第三方主机受到损害，攻击者可以篡改代码并执行任意命令。篡改的代码可用于根据用户会话的上下文在应用程序中执行操作。例如，如果用户通过银行应用程序的身份验证，则被篡改的代码可用于转账或披露财务信息。

如果通过 URL 发送数据，第三方托管还会增加敏感数据泄露给第三方托管的风险。例如，如果 OAuth 令牌通过与托管脚本的连接发送，它会将这些访问令牌泄露给第三方主机，并可能导致攻击者可以使用其访问令牌作为受害者执行命令的情况。

OWASP 有一个备忘单可帮助开发人员针对这个问题编写代码，但自托管静态文件不会对这个特定问题构成威胁。秘密和访问令牌永远不应包含在查询字符串参数中，因为它们可以记录在多个位置（例如，日志和浏览器缓存）。通过自托管文件，开发人员消除了对第三方的敏感数据泄露。

结论

如果性能和安全性是一个问题，自托管静态文件是开发人员支持 Ajax 功能的更好选择。节省的几百毫秒可以改善用户体验、减少加载时间并降低资源成本。出于安全考虑，开发人员降低了敏感数据泄露的风险，并且可以保护源代码免受外部篡改。最后，组织应消除基于对第三方主机的依赖的单点故障，以避免在其云提供商出现意外中断时停机。