如果您想创建一个现代高性能的web应用程序，那么您直接或间接使用Webpack的机会就会很大!
在React开发时你有没有使用CRA (create-react-app) ？ 在开发angular应用时有没有使用 Angular-CLI ？在初始化Vue应用时有没有使用 Vue-cli？
如果上面任一问题你的回答是YES——那么你正在后台使用webpack！

webpack遵循其解析逻辑并生成包。 打包的过程是非常灵活的，以适应各种js文件和捆绑格式，如cjs, ES模块，amd, umd等。然而正因为如此，如果您不知道要交付给webpack的模块类型，那么副作用可能是在意外情况下打包更多的代码。这就是为什么——我们webpack的用户，应该分析并洞察到底是什么进入了我们的包。

我们应该质疑每个模块的存在及其适用性，以及它在特定包和跨包中的存在等等。 但是通常，一个中等复杂度的angular应用程序很容易包含1000-1500个模块。所以，如果一个人试图查看生成的模块，他/她的生命将损失几天!

值得庆幸的是，webpack提供了自己的 --json 选项和一个 Analyzer 来可视化json。它有一些非常有用的插件来提供自己的可视化功能，我发现这对理解我的包内容非常有用!今天，我将介绍我的应用程序包调优经验之一!

当我被要求查看一个应用的性能时，我被告知首页响应需要40秒的时间！对我来说，这有点太慢了。而主页实际上并没有太多的内容，它不应该花那么长时间!

迭代 0

于是我开始分析，以下是一系列截图和修复建议。
我首先创建了一个json文件 并且在https://webpack.github.io/analyse/中打开
下面是我看到的报告：

有了这些信息，我立刻看到了实现更好TTI的第一个机会。那个 4.2MB 的包。我向我的团队解释了如何对路由使用 LazyLoading technique技术，很快我就得到了新代码。 我还检查了应用程序的network选项卡，发现web服务器没有使用gzip content-encoding 头。web服务器配置的一个非常基本的步骤。我指示我的团队解决这个问题。

迭代 1

新的图表如下。

第一个改进—6个bundle而不是1个。主包现在是原来大小的1/3 !

现在我想要关注并理解main bundle中的内容。 虽然从4.2MB到1.8MB(非gzip)是一个很大的改进，但我仍然觉得1.8MB对于首页来说是相当大的代码量。所以我在上面截图的下拉菜单中选择了main bundle并检查了这个bundle中有什么。下面是我看到的……

我的观察:

1. 97%的代码来自node_modules(本质上是库)
2. 来自Angular的各种模块占了55%——大约1MB大小。
3. Moment.js 本地化文件夹占用了 150KB
4. Lodash被添加到多个模块中，每个模块占用50-70KB。
5. D3通过 import * as d3 from 'd3';的方式被引入。这意味着我们包括了整个D3.js库，即使我们没有使用所有的特性。
6. 整个应用程序(或300KB)的16%(显示在node_modules下)实际上是应用程序样式表，它是main bundle的一部分。我不确定样式表是否应该这么大。
   
   所以我决定进一步调查样式表。
   经过检查，我发现我的每个样式表文件都异常大，每个文件的大小都是35kb+ ! 我还看到我们在main bundle中包含了不相关的样式表。在这个当口，我打开编辑器，开始检查SCSS文件。我立即看到一个不正确的scss导入被添加到所有scss文件之上，导致每个scss文件都非常大。我也检查了其他捆绑包，确认了这个问题!
   

其他包也显示了scss文件的大文件大小。
我要求我的团队首先优先修复SCSS导入，因为它会影响所有的包。
迭代 2
下一个迭代立即变得更好。

现在所有的bundle都有1-3%的CSS代码，这多少有点出乎我的意料。
现在我要求我的团队集中精力删除momentjs locale、lodash树抖动、D3树抖动和Angular AOT编译，这样Angular编译器就不会包含在应用程序代码库中了。
现在我对新的编译结果非常满意!





打开每个图像，查看具体的改进

实现上述改进的小结

1. 对于Lodash -我们只需要将lodash-webpack-plugin 添加到webpack配置中。
2. 对于 momentjs — 我们需要使用 context-replacement-plugin 来仅加载我们需要的本地化文件（ include specific moment locales） 。
3. 对于 D3 —我们需要从D3导入特定的导入(适用于D3 v4+)。
4. 对于 AOT 构建— Angular-CLI 的最新版本ng build --prod 已经可以使用AOT。
   下面的表格显示了随着迭代的进行，第一个页面包的大小在下降。
   
   到最后的迭代-第一页下载大小下降了90%!

主要的改进

1. 迭代1— SCSS引用修复。在web服务器中添加GZip内容编码
2. 迭代2— Momentjs, D3, Lodash 修复, AOT 编译

更多的改进想法

1. 至少在你的主页上，不要使用D3+C3/nvD3/Dimple组合。在撰写本文时，C3 nvD3没有使用D3 v4，因此无法使用D3 v4使用的ES模块。这意味着，您可以通过D3+C3/nvD3组合轻松地向包中添加约150kb。我宁愿推荐Chartist—一个非常小的(10kb) SVG基于图表的库(至少在主页上)。
2. 类似地，我们真的应该放弃moment，使用date-fns库。它是一个漂亮的日期操作库，并提供了ES模块，所以它节省了JS文件大小。现在moment.js的内存是51kb，不可能有tree shaking。
3. 尽快升级angular -CLI v1.5和angular v5.0+，利用angular CLI的构建优化器特性来压缩包。
4. 升级到Webpack 4(当可用时)，以大幅提升您的树抖动!

小结:

1. Webpack是一个了不起的和超级灵活的打包库。但是我们必须注意什么样的库是通过webpack打包的。
2. 这可能会对应用程序包大小产生很大影响，从而影响您的第一个页面加载和解析时间。
3. 有多种工具可以帮助您可视化webpack的json输出并获得优化策略。

原文链接：Webpack Bundle Analysis — A necessary step for all React, Angular, Vue application developers!