一行代码,能让项目启动速度提高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插件。使用什么由您决定。
