在vue-cli3中通过webpack减少项目打包体积的办法

以结果为导向

优化之前的打包体积

优化前打包的js

1748958-9e9a00d618cfec6c.png
before_gzip

优化前压缩后的js

js共计4.07M

优化之后的体积

1748958-3618050178b1ba6d.png
after.png

优化后打包的js

1748958-8d81f8fde0b01742.png
before_gzip

优化后压缩后的js

js共计1.58M

一、做了什么

1. 优化vue.config.js

改动点1:加入externals(扩展),对于打包的体积,这个帮助是最大的。

原因:externals在webpack里面是一个很重要的概念,通过externals我们可以将一些重要的库通过cdn的形式加载到页面当中去,这样会提升生产环境中页面的渲染效率

改动点2:通过html-webpack-plugin这个webpack插件将js插入到index.html当中。

通过数据证明:


1748958-7a872fdc19fd76d8.png
add_vue.png

1748958-daed004b1d28f91e.png
no_add.png

每加入一个库,都会减少相应的体积

2. 去掉了mathjs这个库

改动点:sizeCharts.vue这个页面里面有有个计算尺码表的方法使用了mathjs里面的format和add方法,经过改动后使用了decimal.js这个库替代了mathjs。

原因1:decimal这个库的体积比mathjs要小很多,打包后mathjs是478k,而decimal是30k,相差接近16倍,结果可想而知。 原因2:decimal已经在某一个库里面被引用,所以已经被打包进来了,所以干脆用好这个库。

3. 去掉了vue-echarts这个库的使用

改动点:将店铺管理shopMange/index.vue的代码全部注释掉了,这个已经跟产品讨论过了

原因:店铺管理一直没有被真正利用起来,因为在管理员后台有替代品,索性将其注释,正好可以去掉vue-echarts这个库的使用

二、最后说一下由一个bug引起的‘血’案

总结:本地打包后需要打开index.html来看看是否有报错,然后去解决报错。

  • 刚开发完后放到开发环境上面去看了一下,部署后打开页面直接呈空白页面,因为控制台直接报错了,什么错误呢?报了一个TypeError的错误, Cannot read property 'name' of undefined 点进去一看,哇擦,什么鬼?一大堆的变量有q,W,Y,X,J,p,void 0,Z,t等等,不管什么鬼东西,先稍微了解一下代码结构吧。
  • 。。。编译成这样,一般人是不懂了,不过作为这个项目的人,往上翻了一下就看出这个就是mcommon里面的东西,报错的原因是什么呢???脑袋发懵。。。 Z.map(function(e) { t.component(e.name, e) }) 打断点一看,e为undefined,e是从Z那里map出来的,所以Z是从哪里来的,上面一看,Z是由r.Input,r.InputNumber等等一系列组件组成的数组,那么r是从哪里来的呢
  • 继续往上翻,var r = n("5f72"),哇擦,这是什么意思。 嗯。在这个地方打一下断点,刷新页面移上去弹窗显示f Element(),哦,原来是引入了element,既然引入了element,那么为什么会报错呢 算了,试试看下mcommon项目源码,引入element-ui,没有任何问题,那为啥还报错?
  • 控制台打印window.Element(),报错,打印window.Element,显示ƒ Element() { [native code] } 确实是一个函数,但是函数里面空空如也,赶紧去查看head里面是否引入了element,嗯嗯,引入了,那么为什么会是空的呢,看看iview有没有,打印window.iview,一大串。。。 这是怎么回事,去官方网站也打印看看,奇怪了,也是Element() { [native code]},嗯嗯嗯???
  • 。。。5分钟后,还是没有想出办法来,还是得从mcommon着手。 突然,一道精光闪过,我感觉血液有些沸腾,因为我看到了一个关键的变量:$ELEMENT。难道?
  • 赶紧,控制台里面打印一下window.ELEMENT,哈哈,原来是这样。。。 迅速将vue.config.js里面的externas里面的Element改成ELEMENT,保存,打包,刷新页面一气呵成,完美,原来这么简单啊。
  • 很多bug往往就是这么顽皮,原来人家暴露出来的全局变量是ELEMENT,就是这么简单,其实只要是细致一点也许早就将这个报错解决了

仍然存在的问题

  1. emoji里面的图片通过base64之后体积上涨了33%左右,如何破局” 这个问题其实是需要加入压缩图片的loader,因为目前图片是只有打包,并没有进行压缩,但是我暂时没有有效的办法去解决,后面第二次优化的时候把这个问题解决。
  2. mcommon可否减少打包体积,现在有40多k? 这个问题可以去看看rollup的打包过程,然后看看是否有优化的地方,或者看看有没有更好的打包办法。

本次优化提示:

  1. iview的版本有所不同,本地使用的是3.0.1,线上使用的是3.4.1,所以涉及到使用iview的地方会不会有点问题,虽然我已经测试完没有发现问题,但是还是需要同事们一起帮忙看看,以免有所遗漏。

猜你喜欢

转载自blog.csdn.net/weixin_34174105/article/details/90838030