Angular 我应该在生产中使用 vendorChunk答案

【问题标题】：Angular Should I use the vendorChunk in productionAngular 我应该在生产中使用 vendorChunk
【发布时间】：2021-12-23 15:43:12
【问题描述】：

我正在使用 Angular6，我想知道在生产中将 "vendorChunk" 设置为 true 或 false 是否更好。我知道它的作用，但我不确定在生产中使用的最佳价值。

【问题讨论】：

标签： angular

【解决方案1】：

这取决于您的用例。

没有单独的供应商块的好处是您可以获得更小的捆绑包大小。小多少取决于您的应用程序。我建议尝试使用和不使用标志的构建，看看是否有显着差异。

另一方面，启用vendorChunk 的主要优点是用户将只能下载更改后的客户端代码，而无需第三方代码（不太可能经常更改）。

总结：

将vendorChunk 设置为true 如果：

将vendorChunk 设置为false 如果：

【讨论】：

快速提问，为什么不分离供应商块会使捆绑包更小？
我们可以添加：将 vendorChunk 设置为 false 如果： - 捆绑包几乎只包含自己的代码（少量第三方库）？（不确定句子结构...）
@Lani 分离供应商使代码更大，而不是更小，我相信你误读了。原因是如果某些库（在 main.js 和 vendor.js 中）在代码中只出现一次，则可以更好地编译代码。

【解决方案2】：

我正在搜索相同的问题，并且在 Angular 文档 https://angular.io/cli/build 中，说该选项应该仅用于开发。

【讨论】：

【解决方案3】：

Devs say 在生产中 vendor.js 将“经常获得不同的供应商块哈希，即使仅更改应用程序代码也是如此”。因此看起来 vendorChunk=true 在生产中没有多大用处。（虽然不能检查）

但是我刚刚检查了我们的生产应用程序的 budle 大小，vendorChunk=false
main.js (1'996'389 字节)

对于 vendorChunk=true
main.js (193'223 字节) + vendor.js (1'804'540 字节) = 1'997'763 字节

我们赢得了 1374 字节，这不算什么，但当然可能取决于应用程序。至于我，我认为最好坚持默认行为。（开发为 true，prod 为 false）

【讨论】：

【解决方案4】：

我在公司遇到的一个很好的边缘案例可能是在一个应用程序中使用多个 Angular 组件，该应用程序大量使用具有不同框架的微前端。

例如，假设您在 React 应用程序中需要 Angular 组件。如果您在这种情况下使用多个 Angular 组件，则对于依赖于相同模块的所有使用的组件，单独的 vendorChunk 只能加载一次。

这将缩短加载时间，因为每个组件只需要加载其mainChunk 即可相应地工作。

【讨论】：

【解决方案5】：

简而言之，这取决于。

如果您的网站每人访问一次，最好不要访问它，因为好处来自缓存供应商块。

你可以或多或少地把问题换成这些

以下是一些示例：

假设您有一个每周访问一次的网站，并且您每周进行更新。让用户每次都下载你所有的 node_modules 可能有点过头了，所以你把它放在 vendor.[hash].js 和 cache-control: <around a year> 中，这样如果浏览器可以使用它已经下载的那个。
如果您的应用可以一次性将点击转化为销售。然后让他们下载单个 main.[hash].js 文件通常会加快加载时间。

所以这取决于，两者都有好处，这就是为什么它是一种选择。

【讨论】：