webpack 解读

关于 webpack 打包性能优化的话题说过很多了。除了基本的 babel 缓存， common chunk 抽取，DLL 的提取，happypack 的使用；还有利用 hash 值不变进行网络缓存的方法。但好奇的是这所谓的缩短打包时长能到什么地步，利用周末进行了测试。

场景：项目打包时间未进行优化之前，初次打包 82s，再次打包 46s，且打出来的 entry 包达 20M+；故计划利用 DLL 抽取 React、Redux、moment、antd 等常用第三方包，加速打包。

问题：DLL 文件抽取成功，加上其他优化方式，时间缩短到 35s 左右，但打出来的包无法使用，因项目中用了 sharedworker，而 sharedworker 环境中无法读取前台的 dll 文件，报错。

解法：

1. ☹️shared-worker-loader。首先依赖 webpack 1.0，而项目是 webpack 3.0 的，不兼容，报错，并且非官方，不维护了。
2. 直接 importScripts('dll 文件 url')。包可用，不再报找不到 dll 全局变量的错，但问题是 dll 是基于整个项目抽取的，压缩后 1.7M，未压缩 5.4M，sharedworker 中只用到了几个第三方包，但需要在前台发起一次请求，在 worker 层又发起一次请求，浪费。
3. 添加一个 Plugin。由于打包时解析 manifest.json，只要 module 构建过程中涉及到 manifest 中存在的包，则代理到 dll 文件中，但是并不能忽略某一个 entry point 或者 chunk，设想在 webpack 的 optimize-tree 阶段把代理到 dll 上的 module 重新以源代码的形式放到设置为 excludes 的 entrypoint 或 chunk 中。

参考：

1. 玩转 webpack
2. 细说 webpack 之流程篇
3. webpack 性能优化之 DLL
4. webpack plugin 内部运行机制
5. 深入浅出 webpack