我是如何用 Webpack 虐待代码尺寸的 (第三回合)

上文说第二次重构...

解释一下, 原因是 im 这个项目希望可以做到平台化, 具体来说就是, 这个项目拆成两个部分, 一部分是基础功能, 比如正常的聊天, 头像, 表情等, 另一部分是定制化的, 比如不同的业务加入不同的卡片(定制样式和功能的消息, 并且可以自带操作), 不同的流程处理, 以及各种根据业务定制的功能

所以这一次做了一个项目拆分, 将一个项目拆成了两个项目, 一个是公共项目, 一个是业务项目

再通过一个壳桥接两个项目, 分别构建然后利用 window 全局变量进行沟通

项目拆分 230K -> 392K(247K + 145K)

由于是两个项目分别构建, 下面的分析图会有两份

公共项目

业务项目

重构说明

主要拆分了公共项目和业务项目, 并且新增了 vConsole, Raven 等调试和查错工具, 以及部分功能的新增

分析

经过项目拆分后可以很明显发现很多公共库出现了两份, 导致整个项目尺寸增大

vConsole 被误打入到代码里

修改编译方式, 合并到同一个项目, 并且拆分 chunk, 去掉生产库中的 vconsole

分析

mint-ui 占用过多, 但项目中只用了一个 toast

图片占用过大影响了首屏展示速度

随着业务增长, 又增加了30K+ ...

增加了 runtimeChunk, 为了固定 chunk 的 hash, 减少线上更新带来的加载消耗, 具体不多少, 关于 runtimeChunk 的说明就让更专业的人来吧~~

话说回来 , 问题依然是之前的问题

页面前置代码到达300K+ 对于移动端来讲已经岌岌可危了, 还是动手精简吧

manifest 很小, 没有必要单独请求阻塞后面 js 的加载, 直接打入到 html 中

mint-ui 可以通过 babel 插件实现按需引入, 但是由于 ui 更新, 重新做了 toast, 不需要 mint-ui 了

引入 imagemin 压缩图片, 并且使用有损压缩的算法

压缩后肉眼在手机上查看几乎和原图一样

好了, 目前看来这个项目比较明显的优化点已经不多了, 细致的优化还有 protobuf 改用 light 版, 拆分异步模块以加快首屏加载速度, 以及 pwa 等

这些就慢慢优化吧

总结一下

目前用到的优化方法

总之, "没有银弹", 需要根据实际项目针对分析, 才能找到可优化的点

这里只是抛砖引玉记录了这个项目的优化过程, 希望对各位前端同学有些帮助

各位同学有更多优化的方法, 还请评论或者私信告诉我, 一起交流交流~~~

----

再次广告

欢迎关注我的知乎账号, 关注后续优化操作, 想了解网页版 socket 和 IM 相关的内容也可以关注, 后面会有相关的文章