关于 webpack 打包性能优化的话题说过很多了。除了基本的 babel 缓存, common chunk 抽取,DLL 的提取,happypack 的使用;还有利用 hash 值不变进行网络缓存的方法。但好奇的是这所谓的缩短打包时长能到什么地步,利用周末进行了测试。
场景:项目打包时间未进行优化之前,初次打包 82s,再次打包 46s,且打出来的 entry 包达 20M+;故计划利用 DLL 抽取 React、Redux、moment、antd 等常用第三方包,加速打包。
问题:DLL 文件抽取成功,加上其他优化方式,时间缩短到 35s 左右,但打出来的包无法使用,因项目中用了 sharedworker,而 sharedworker 环境中无法读取前台的 dll 文件,报错。
解法:
- ☹️shared-worker-loader。首先依赖 webpack 1.0,而项目是 webpack 3.0 的,不兼容,报错,并且非官方,不维护了。
- 🙂直接 importScripts('dll 文件 url')。包可用,不再报找不到 dll 全局变量的错,但问题是 dll 是基于整个项目抽取的,压缩后 1.7M,未压缩 5.4M,sharedworker 中只用到了几个第三方包,但需要在前台发起一次请求,在 worker 层又发起一次请求,浪费。
- 😀 添加一个 Plugin。由于打包时解析 manifest.json,只要 module 构建过程中涉及到 manifest 中存在的包,则代理到 dll 文件中,但是并不能忽略某一个 entry point 或者 chunk,设想在 webpack 的 optimize-tree 阶段把代理到 dll 上的 module 重新以源代码的形式放到设置为 excludes 的 entrypoint 或 chunk 中。
参考:
网友评论