关于 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 中。
参考：
