Web性能优化: 使用Webpack分离数据的正确方法
制定向用户提供文件的最佳方式可能是一项棘手的工作。 有很多不同的场景,不同的技术,不同的术语。 在这篇文章中,我希望给你所有你需要的东西,这样你就可以:
根据 Webpack glossary,有两种不同类型的文件分割。 这些术语听起来可以互换,但显然不是。 Webpack 文件分离包括两个部分,一个是 Bundle splitting,一个是 Code splitting:
第二个听起来更吸引人,不是吗?事实上,关于这个问题的许多文章似乎都假设这是制作更小的JavaScript 文件的惟一值得的情况。 但我在这里要告诉你的是,第一个在很多网站上都更有价值,应该是你为所有网站做的第一件事。 就让我们一探究竟吧。 Bundle splitting bundle splitting 背后的思想非常简单,如果你有一个巨大的文件,并且更改了一行代码,那么用户必须再次下载整个文件。但是如果将其分成两个文件,那么用户只需要下载更改的文件,浏览器将从缓存中提供另一个文件。 值得注意的是,由于 bundle splitting 都是关于缓存的,所以对于第一次访问来说没有什么区别。 (我认为太多关于性能的讨论都是关于第一次访问一个站点,或许部分原因是“第一印象很重要”,部分原因是它很好、很容易衡量。 对于经常访问的用户来说,量化性能增强所带来的影响可能比较棘手,但是我们必须进行量化! 这将需要一个电子表格,因此我们需要锁定一组非常特定的环境,我们可以针对这些环境测试每个缓存策略。 这是我在前一段中提到的情况:
某些类型的人(比如我)会尝试让这个场景尽可能的真实。不要这样做。实际情况并不重要,稍后我们将找出原因。 基线 假设我们的 JavaScript 包的总容量是400 KB,目前我们将它作为一个名为 main.js 的文件加载。 我们有一个 Webpack 配置如下(我省略了一些无关的配置):
对于那些新的缓存破坏:任何时候我说 main.js,我实际上是指 main.xMePWxHo.js,其中里面的字符串是文件内容的散列。这意味着不同的文件名 当应用程序中的代码发生更改时,从而强制浏览器下载新文件。 每周当我们对站点进行一些新的更改时,这个包的 contenthash 都会发生变化。因此,Alice 每周都要访问我们的站点并下载一个新的 400kb 文件。 如果我们把这些事件做成一张表格,它会是这样的。 也就是10周内, 4.12 MB, 我们可以做得更好。 分解 vendor 包 让我们将包分成 main.js 和 vendor.js 文件。
Webpack4 为你做最好的事情,而没有告诉你想要如何拆分包。这导致我们对 webpack 是如何分包的知之甚少,结果有人会问 “你到底在对我的包裹做什么?” 添加 optimization.splitChunks.chunks ='all'的一种说法是 “将 node_modules 中的所有内容放入名为 vendors~main.js 的文件中”。 (编辑:ASP站长网) |