我们知道，webpack种chunks的默认配置是async，
也就是说webpack默认只对异步代码进行代码分割。
为什么会这样呢？
之前，我们引用的
jquery或lodash这样的库，
我们对这样的代码进行代码分割，不是可以有效提升代码的性能吗？
实际上，当我们把jquery或lodash这样的库打包生成一个单独的文件的时候，
第一次访问的时候，我们加载就可以了，
第二次访问的时候，我们就可以借助缓存，提高我们的加载速度。
但这样，也只不过是提高我们第二次访问页面的速度。
那真正对页面性能做优化，
webpack希望达到的一个效果是第一次访问页面的时候，加载速度就是最快的，
如果想实现这样的效果，
靠把jquery或lodash这样的库打包生成一个单独的文件，是满足不了我们的需求的。
那webpack真正希望我们编写代码的方式是什么样子的呢？
1.假如我们的index.js里有如下代码：
document.addEventListener('click', () => {
const element = document.createElement('div');
element.innerHTML = 'LEE YANG';
document.body.appendChild(element)
})
//实现的功能很简单，
//当我们点击页面的时候，生成一个div标签，设置标签内容为LEE YANG,
//然后把标签挂载到页面上
2.然后我们打包运行npm run build
看起来，我们写的代码是没有任何问题的，
但是这段代码完全没有优化的空间了吗？
或者说，这是不是最标准的webpack推荐的一种代码编写的方式呢?
实际上不是的。
3.我们打开控制台，然后输入commond+shift+p（MAC命令）或者ctrl+shift+p(window命令)，
就可以出现这个界面
4.然后搜索show coverage这个关键词，
搜到后点击这个功能
5.点击之后会出现下边这个界面
6.然后点击黑色圆点，开启录制功能
7.开启后，圆点变成红色，
然后我们刷新页面，就可以看到页面加载了一个文化是main.js文件，
我们可以看到这个文件的利用率，只有74.7%
8.我们点击main.js就可以看到，
我们就可以看到哪些代码main.js是在这个页面被用到的部分（绿色），
哪些是mian.js在这个界面上没有被用到的部分（红色）
9.通过上边的图，我们可以看到，页面刷新，
我们往DOM上绑定了一个click事件，
这个事件回调里的代码现在是没有任何用处的，
因为页面加载了之后，只有点击了页面之后，才会用到这些代码，
我们现在点击一下页面，可以看到，代码被用到了，颜色变成了绿色
而一开始，刚加载的时候，
click事件回调里的代码根本就不会执行，
不会执行的代码我们却让页面一加载的时候就把它下载下来，
实际上就会浪费页面加载的性能，
那webpack希望，页面交互的代码，应该怎么写呢？
10.应该把交互的代码放到一个异步加载的模块里去写，我们改造一下代码，新建一个click.js文件
11.然后在 index.js里引入,下边代码的意思是，当我们点击的时候，异步引入handleClick方法，并执行
12.然后我们打包一下npm run build,打包后，
打开dist下的index.html,
我们再打开show coverage,
发现我们的代码利用率，从刚才的74.7%变成了现在的79.7%
-
之所以利用率变高，
是因为，一开始页面加载的时候，并没有加载引入handleClick方法这个业务逻辑，
而是在我们点击的时候，才开始加载1.jsimage -
而
1.js就是我们写的业务逻辑image 这才是让页面加载速度最快的一种正确的编写方式
所以，我们在写高性能前端代码的时候,
现在应该重点考虑的，其实不是缓存这样的东西，
而是代码的使用率(使用率越高，我们看到首屏的加载时间越短)
所以`webpack`它在打包过程种，
是希望我们尽可能多写这种`异步加载`的代码的。
同时它会认为，同步的代码打包在一起，生成一个`vendor.js`意义是不大的，
只有多写一些异步的代码，
才能让我们网站的性能真正得到提升，
这也就是为什么`webpack`的配置项里`splitChunks`值默认为`async`,
也就是说，
它认为只有异步组件才能真正的提升网页的打包性能。
而同步的代码只能增加一个缓存，实际上对性能的提升是非常有限的。
以慕课网为例查看利用率：
1.打开控制台 ctrl+shipt+p
2.整体js利用率70%
3.一共这个页面加载了584kb的js文件
4.但实际上在页面渲染的时候真正有用的js文件409kb
5.还有184kb的内容理论上是可以被优化掉的
