一行代码，能让项目启动速度提高70%以上70左右，效果还是有的，只用了一行代码。👇下面说一下找到这行代码的过程。不耐烦的可以直接跳到文章底部直接看结论。项目背景项目是一个简单的vue项目，但是公司内部包含了一层vue-cli，但是影响不大。别的不说，正常的H5网页是不会用太多插件的，为了控制项目的大小。项目分析既然决定要优化了，首先就要对项目进行分析，先用speed-measure-webpack-plugin和webpack-bundle-analyzer来分析一下，具体配置这里就不说了，很简单，网上一搜Heap，结论直接看这里。首先是项目运行时间：可以看到，基本上耗时大的是eslint-loader和vue-loader，一个耗时40多秒，一个耗时30多秒，耗时一个很多资源。接下来我们来看具体的封装解析👇这将快速定位问题的根本原因。不看右边的chunk-vendors，只看左边的chunk-page，里面的page太多了，对应的文件也多，直接导致时间长——使用eslint-loader和vue-loader。文件那么多，每一个都要检查很长时间。其实右侧还可以继续优化，但是感觉没必要，swiper其实不大。那么现在就可以具体定位问题了。由于项目是多SPA应用，所以.vue文件比较多。项目启动时检查加载eslint的时间过长，导致项目启动时间过长。解决方案找到问题后，您必须解决问题。初步解决方案有两种：killeslint，本地编译时不检查缓存。代码格式，虽然在提交代码的时候有相应的钩子来格式化代码，但是在开发过程中的提示可以更好的帮助我们形成合理的编码方式。所以现在唯一剩下的解决办法就是进行缓存操作，然后笔者开始寻找相关的插件来更好的缓存。尝试先用hard-source-webpack-plugin解决问题，它为模块提供了一个中间的缓存步骤，但是项目要运行两次，第一次构建时间正常，第二次可以节省90%左右的时间。很多文章都推荐这个插件，看起来很不错，使用起来也很简单，只需👇:plugins:[newHardSourceWebpackPlugin()]就可以了。就这么简单？真的就这么简单，但又不简单。如果就此打住，我就不会折腾一个下午了。它就像安装一样简单：npmihard-source-webpack-plugin-D然后配置就像👆一样简单，然后重新启动项目，你猜怎么着？报错！是什么原因？是因为speed-measure-webpack-plugin或webpack-bundle-analyzer其中之一，为什么？原因其实笔者也不是很清楚，因为启动时报错是这样的：Cannotfindmodule'webpack/lib/DependenciesBlockVariable'哦，这个错误有点出乎意料，怎么会突然报webpack错误呢？笔者也是百思不得其解，自己去谷歌也没有人遇到过这样的问题。不得已只能去hard-source-webpack-plugin的github上看issue，发现确实有人遇到过这个问题。他们的解决办法是降低webpack的版本，但是我这里不行，因为他们都是在vue-cli里面集成的，而且这个是在公司内部打包的，所以降版本是不可能的。第一次转机呢？真的没有别的办法。我试着搜索了DependenciesBlockVariable的相关内容。这个时候，事情发生了微妙的变化。原来webpack5中去掉了这个功能。是不是因为公司内部的vue-cli使用的是webpack5.x版本？img作者立马在node_modules中找到插件，然后查看package.json文件，却失望的发现webpack的版本是4.2.6，绝望。真的不可能吗？现在你已经打开了webpack文档，好好看看吧。说实话，这个文档笔者看了N遍，每次看都有一个小小的惊喜，功能竟然这么多。翻看的时候看到了这个小功能👇：哦，有点小惊喜，这个功能很简单，这不是我想要的吗？然后快速做出决定并转到vue.config.js，你猜怎么着？完成！虽然文档是针对webpack5.0的，但是笔者发现4.x版本也有这个功能。或许再弱一些，也能起到一定的作用。重启几次项目后，发现启动时间稳定了，效果真的不错~img直接为我工作了14秒。虽然不稳定，但这已经是目前状态下最好的解决办法了。所以最后的代码是：chainWebpack:(config)=>{config.cache(true)}使用chainWebpack的原因是项目中其实没有独立的webpack.config.js文件，所以只能放在vue.config.js文件，使用chainWebpack将配置插入到webpack中。你以为就在这里？太容易了。解决了第二个转折点的问题之后，当然要把speed-measure-webpack-plugin和webpack-bundle-analyzer这两个插件删掉，然后整理一下代码推完。但是作者还是不死心，为什么hard-source-webpack-plugin不好用呢？不应该啊，为什么别人可以用，自己的项目不行呢？为了再次操作，为了更好的优化项目的启动时间，笔者再次安装了hard-source-webpack-plugin并进行了配置：chainWebpack:(config)=>{config.plugin('cache').use(这次又是HardSourceWebpackPlugin)}，你猜怎么着？完成！为了避免再次启动失败，笔者这次没有使用speed-measure-webpack-plugin和webpack-bundle-analyzer这两个插件，所以启动时间无法具体预估，但目测时间都在10秒，强。所以hard-source-webpack-plugin失败的原因可能是这两个统计插件的原因。得再试一次，不然我就看不懂GG了。结论这里的结论很简单，有两个版本。首先，如果项目能使用hard-source-webpack-plugin就很方便了，搞定了，什么都不用做，所以这行代码是👇:config.plugin('cache').use(HardSourceWebpackPlugin)大概快了90%以上，官方时间没有虚报。其次，如果你不能使用hard-source-webpack-plugin，那就放弃吧。试试webpack自带的缓存功能还是不错的。虽然不如hard-source-webpack-plugin，但可以提高70%左右的启动速度。时间，所以这行代码是👇:config.cache(true)复制代码，不需要安装任何插件，一步到位。这两种方法其实是可行的。稳定性和效果上还是hard-source-webpack-plugin好一些，但是cache的好处是不需要额外安装webpack插件。使用什么由您决定。
