關(guān)于 webpack 打包性能優(yōu)化的話題說過很多了墓毒。除了基本的 babel 緩存吓揪， common chunk 抽取，DLL 的提取蚁鳖，happypack 的使用磺芭；還有利用 hash 值不變進行網(wǎng)絡(luò)緩存的方法。但好奇的是這所謂的縮短打包時長能到什么地步醉箕，利用周末進行了測試钾腺。
場景：項目打包時間未進行優(yōu)化之前，初次打包 82s讥裤，再次打包 46s放棒，且打出來的 entry 包達 20M+；故計劃利用 DLL 抽取 React己英、Redux间螟、moment、antd 等常用第三方包，加速打包厢破。
問題：DLL 文件抽取成功荣瑟，加上其他優(yōu)化方式，時間縮短到 35s 左右摩泪，但打出來的包無法使用笆焰，因項目中用了 sharedworker，而 sharedworker 環(huán)境中無法讀取前臺的 dll 文件见坑，報錯嚷掠。
解法：
- ??shared-worker-loader。首先依賴 webpack 1.0荞驴，而項目是 webpack 3.0 的不皆，不兼容，報錯熊楼，并且非官方霹娄，不維護了。
- ??直接 importScripts('dll 文件 url')孙蒙。包可用项棠，不再報找不到 dll 全局變量的錯，但問題是 dll 是基于整個項目抽取的挎峦，壓縮后 1.7M，未壓縮 5.4M合瓢，sharedworker 中只用到了幾個第三方包坦胶，但需要在前臺發(fā)起一次請求，在 worker 層又發(fā)起一次請求晴楔，浪費顿苇。
- ?? 添加一個 Plugin。由于打包時解析 manifest.json税弃，只要 module 構(gòu)建過程中涉及到 manifest 中存在的包纪岁，則代理到 dll 文件中，但是并不能忽略某一個 entry point 或者 chunk则果，設(shè)想在 webpack 的 optimize-tree 階段把代理到 dll 上的 module 重新以源代碼的形式放到設(shè)置為 excludes 的 entrypoint 或 chunk 中幔翰。
參考：
