如何优化服务和加载JavaScript文件？

我希望有更多全球规模web应用经验的人能够澄清一些问题、假设和可能的误解

让我们假设一个站点（大量的客户端/动态组件），它在全球拥有数十万用户，并且从一个位置（比如中欧）提供服务

如果应用程序依赖于流行的JavaScript库，那么最好从Google CDN获取它，并将其编译成一个简化的JS文件（以及所有特定于应用程序的JavaScript），或者从Google CDN单独加载它

Assetic VS：加载一个JS文件或并行加载所有脚本（按依赖项的顺序执行）更有意义吗

我的假设（请纠正我）：

将所有特定于应用程序的/本地JS代码编译成一个文件，使用诸如Google的流行库CDN等。但是通过headjs并行加载所有这些代码似乎是最优的，但我不确定。服务器端将第三方JS和特定于应用程序的JS编译成一个文件似乎几乎无法达到使用CDN的目的，因为该库可能会缓存在用户的某个位置

除了缓存，从Google的CDN下载第三方库可能比托管应用程序的中央服务器更快

如果发布了一个新版本的流行JS库，并大大提高了性能，那么将使用应用程序进行测试，然后实施：

• 如果所有的JS都被编译成一个文件，那么即使应用程序代码没有改变，每个用户都必须重新下载这个文件
• 如果第三方脚本是从CDN加载的，那么用户只需从CDN（或从缓存某处）下载新版本

在所描述的情况下，是否存在以下任何合理的担忧

• 某些用户（或浏览器）一次只能与一个主机名建立一定数量的连接，因此从第三方CDN检索某些脚本将导致总体上更快的加载时间
• 某些用户可能在受限环境中使用该应用程序，因此该应用程序的域可能是白名单，但不是CDN的域。（如果可能的话，这是一个现实问题，那么在出现故障时，是否可以尝试从CDN加载和从中央服务器加载？）

由于许多原因，包括更改/依赖项/需求，许多小js文件比少数几个大js文件要好

当前的任何web服务器（Apache/IIS和许多其他服务器）都可以非常高效地处理JavaScript/css/html和任何其他静态内容，大多数情况下，一台web服务器每秒都可以处理100s和1000s请求，而且在任何情况下，这些静态内容都可能缓存在客户端和服务器之间的某个位置.

使用任何外部（不受您控制）存储库来存储您希望在生产环境中使用的代码是不允许的（对我和许多其他人来说），您不希望整个站点JavaScript功能突然出现灾难性的、不可恢复的故障，因为某个地方有人未经思考或检查就按下了提交

使用 像谷歌的流行图书馆等CDN，但加载所有 这些并行的头JS似乎是最优的

我认为这基本上是正确的。不要将多个外部库合并到一个文件中，因为您似乎知道这将否定大多数用户浏览器已经缓存（单个）资源的情况

对于您自己的特定于应用程序的JS代码，您可能需要考虑更新频率。例如，如果有一个功能核心不经常更改，但一些较小的组件可能会定期更改，那么只将核心编译（我假设您的意思是缩小/压缩）为一个文件，同时继续零碎地为较小的部分提供服务可能是有意义的

您的决定还应该考虑JS资产的大小。如果这不太可能，但可能您正在提供大量JavaScript，那么将所有JavaScript连接到一个文件可能会适得其反，因为一些客户端（如移动设备）对缓存内容有非常严格的限制。在这种情况下，你最好还是为一些较小的资产服务

这些只是你需要注意的随机花絮。我想说的主要一点是，你的第一直觉（如上所述）可能是正确的方法

将所有特定于应用程序/本地JS代码编译到一个文件中

由于我们的一些关键目标是和，这是一种被广泛采用的最佳实践

我们可能不考虑这样做的主要情况是频繁出现高速缓存失效的情况，即当我们对代码进行更改时。这里总会有权衡：为单个文件提供服务很可能会提高缓存失效率，而为多个单独的文件提供服务可能会导致缓存为空的用户启动较慢

因此，偶尔内联一些特定于页面的JavaScript并不像有些人所说的那样邪恶。不过，一般来说，将JS连接并缩小为一个文件是非常好的第一步

在流行的图书馆中使用像谷歌这样的CDN，等等

如果我们谈论的库中我们正在使用的代码是相当不可变的，即不太可能受到缓存失效的影响，那么我可能更倾向于通过将HTTP请求包装到您的整体本地JS文件中来保存它们。对于大量基于（例如）特定jQuery版本的大型代码库来说，尤其如此。在这种情况下，会影响库版本