使用Webpack分离数据的正确方法

1. 割策略最适合你的网站和用户
2.  知道怎么做

根据 Webpack glossary，有两种不同类型的文件分割。 这些术语听起来可以互换，但显然不是。

Webpack 文件分离包括两个部分，一个是 Bundle splitting，一个是 Code splitting:

•  Bundle splitting: 创建更多更小的文件，并行加载，以获得更好的缓存效果，主要作用就是使浏览器并行下载，提高下载速度。并且运用浏览器缓存，只有代码被修改，文件名中的哈希值改变了才会去再次加载。
•  Code splitting：只加载用户最需要的部分，其余的代码都遵从懒加载的策略，主要的作用就是加快页面的加载速度，不加载不必要的代码。

第二个听起来更吸引人，不是吗?事实上，关于这个问题的许多文章似乎都假设这是制作更小的JavaScript 文件的惟一值得的情况。

但我在这里要告诉你的是，***个在很多网站上都更有价值，应该是你为所有网站做的***件事。

就让我们一探究竟吧。

Bundle splitting

bundle splitting 背后的思想非常简单，如果你有一个巨大的文件，并且更改了一行代码，那么用户必须再次下载整个文件。但是如果将其分成两个文件，那么用户只需要下载更改的文件，浏览器将从缓存中提供另一个文件。

值得注意的是，由于 bundle splitting 都是关于缓存的，所以对于***次访问来说没有什么区别。

(我认为太多关于性能的讨论都是关于***次访问一个站点，或许部分原因是“***印象很重要”，部分原因是它很好、很容易衡量。

对于经常访问的用户来说，量化性能增强所带来的影响可能比较棘手，但是我们必须进行量化!

这将需要一个电子表格，因此我们需要锁定一组非常特定的环境，我们可以针对这些环境测试每个缓存策略。

这是我在前一段中提到的情况:

•  Alice 每周访问我们的网站一次，持续 10 周
•  我们每周更新一次网站
•  我们每周都会更新我们的“产品列表”页面
•  我们也有一个“产品详细信息”页面，但我们目前还没有开发
•  在第 5 周，我们向站点添加了一个新的 npm 包
•  在第 8 周，我们更新了一个现有的 npm 包

某些类型的人(比如我)会尝试让这个场景尽可能的真实。不要这样做。实际情况并不重要，稍后我们将找出原因。

基线

假设我们的 JavaScript 包的总容量是400 KB，目前我们将它作为一个名为 main.js 的文件加载。

我们有一个 Webpack 配置如下(我省略了一些无关的配置):

（编辑：开发网_郴州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!