webpack優化編譯速度
① 編譯優化-HappyPack
多線程（多進程模擬）支持
HappyPack的工作原理：在Webpack和Loader之間多加了一層，改成了Webpack並不是直接去和某個Loader進行工作，而是Webpack test到了需要編譯的某個類型的資源模塊後，將該資源的處理任務交給了HappyPack，由HappyPack在內部線程池中進行任務調度，分配一個線程調用處理該類型資源的Loader來處理這個資源，完成後上報處理結果，最後HappyPack把處理結果返回給Webpack，最後由Webpack輸出到目的路徑。通過這一系列操作，將原本都在一個Node.js線程內的工作，分配到了不同的線程（進程）中並行處理。
使用方法如下：
首先引入HappyPack並創建線程池：
替換之前的Loader為HappyPack的插件：
將原Loader中的配置，移動到對應插件中：
Webpack v4編譯速度優化實踐
② 如何解決webpack打包後，dist文件過大的問題
去除不必要的插件
剛開始用 webpack 的時候，開發環境和生產環境用的是同一個 webpack 配置文件，導致生產環境打包的 JS 文件包含了一大堆沒必要的插件，比如 HotMoleReplacementPlugin, NoErrorsPlugin... 這時候不管用什麼優化方式，都沒多大效果。所以，如果你打包後的文件非常大的話，先檢查下是不是包含了這些插件。
提取第三方庫
像 react 這個庫的核心代碼就有 627 KB，這樣和我們的源代碼放在一起打包，體積肯定會很大。所以可以在 webpack 中設置
{
entry: {
bundle: 'app'
vendor: ['react']
}
plugins: {
new webpack.optimize.CommonsChunkPlugin('vendor', 'vendor.js')
}
}
這樣打包之後就會多出一個 vendor.js 文件，之後在引入我們自己的代碼之前，都要先引入這個文件。比如在 index.html 中
<script src="/build/vendor.js"></script>
<script src="/build/bundle.js"></script>
除了這種方式之外，還可以通過引用外部文件的方式引入第三方庫，比如像下面的配置
{
externals: {
'react': 'React'
}
}
externals 對象的 key 是給 require 時用的，比如 require('react')，對象的 value 表示的是如何在 global 中訪問到該對象，這里是 window.React。這時候 index.html 就變成下面這樣
<script src="//cdn.bootcss.com/react/0.14.7/react.min.js"></script>
<script src="/build/bundle.js"></script>
當然，個人更推薦第一種方式。
代碼壓縮
webpack 自帶了一個壓縮插件 UglifyJsPlugin，只需要在配置文件中引入即可。
{
plugins: [
new webpack.optimize.UglifyJsPlugin({
compress: {
warnings: false
}
})
]
}
加入了這個插件之後，編譯的速度會明顯變慢，所以一般只在生產環境啟用。
另外，伺服器端還可以開啟 gzip 壓縮，優化的效果更明顯。
代碼分割
什麼是代碼分割呢？我們知道，一般載入一個網頁都會把全部的 js 代碼都載入下來。但是對於 web app 來說，我們更想要的是只載入當前 UI 的代碼，沒有點擊的部分不載入。
看起來好像挺麻煩，但是通過 webpack 的 code split 以及配合 react router 就可以方便實現。具體的例子可以看下 react router 的官方示例 huge apps。不過這里還是講下之前配置踩過的坑。
code split 是不支持 ES6 的模塊系統的，所以在導入和導出的時候千萬要注意，特別是導出。如果你導出組件的時候用 ES6 的方式，這時候不管導入是用 CommomJs 還是 AMD，都會失敗，而且還不會報錯！
當然會踩到這個坑也是因為我剛剛才用 NodeJS，而且一入門就是用 ES6 的風格。除了這個之外，還有一點也要注意，在生產環境的 webpack 配置文件中，要加上 publicPath
output: {
path: xxx,
publicPath: yyy,
filename: 'bundle.js'
}
不然的話，webpack 在載入 chunk 的時候，路徑會出錯。
設置緩存
開始這個小節之前，可以先看下大神的一篇文章：大公司里怎樣開發和部署前端代碼。
對於靜態文件，第一次獲取之後，文件內容沒改變的話，瀏覽器直接讀取緩存文件即可。那如果緩存設置過長，文件要更新怎麼辦呢？嗯，以文件內容的 MD5 作為文件名就是一個不錯的解決方案。來看下用 webpack 應該怎樣實現
output: {
path: xxx,
publicPath: yyy,
filename: '[name]-[chunkhash:6].js'
}
打包後的文件名加入了 hash 值
const bundler = webpack(config)
bundler.run((err, stats) => {
let assets = stats.toJson().assets
let name
for (let i = 0; i < assets.length; i++) {
if (assets[i].name.startsWith('main')) {
name = assets[i].name
break
}
}
fs.stat(config.buildTemplatePath, (err, stats) => {
if (err) {
fs.mkdirSync(config.buildTemplatePath)
}
writeTemplate(name)
})
})
手動調用 webpack 的 API，獲取打包後的文件名，通過 writeTemplate 更新 html 代碼。完整代碼猛戳 gitst。
③ 從 Webpack 到 Snowpack, 編譯速度提升十倍以上——TRPG Engine遷移小記
原文地址: http://moonrailgun.com/posts/74598ef5/
TRPG Engine 經過長久以來的迭代，項目已經顯得非常臃腫了。數分鍾的全量編譯, 每次按下保存都會觸發一次 10s 到 1m 不等的增量編譯讓我苦不堪言, 龐大的依賴使其每一次編譯都會涉及很多文件和很多包，長時的編譯時間大大降低了開發效率與迭代速度。
經過一段時間的考察，我選擇了 Snowpack 作為解決方案。與 Webpack 不同的是，除了第一次的全量編譯以外， Snowpack 的增量編譯不會涉及到龐大的 node_moles 文件夾, 准確來說只會編譯變更文件本身。甚至於如果沒有對依賴進行變更，下次的全量編譯會直接動用之前編譯的文件緩存，不需要花時間等待 node_moles 的編譯。
為什麼會這么快？這是由於 Snowpack 本身的實現與設計哲學有關的。相比 Webpack , Snowpack 利用了現代瀏覽器的本身的 mole 系統，跳過復雜的模型之間的組織編譯過程而只關注於變更文件本身的編譯，這樣當然快了。
拿 Snowpack 官方的一張圖來說:
snowpack 的最我譯單位是文件，而 webpack 的最我譯單位為 chunk , 而 chunk 還需要額外的計算, 不論是編譯部分還是編譯後的組裝部分。snowpack的設計邏輯天生決定了她的速度。
優化前(使用 webpack ):
全量編譯:
增量編譯:
全量請求用時:
優化後(使用 snowpack ):
全量編譯:
增量編譯:
(看不到編譯用時，但是體感在1s內. 而且該效果在電腦運行其他應用時更加顯著)
全量請求用時:
以上測試是保證電腦在空閑時間，且保存與操作內容為同一文件
該用時已經是平時操作的最快時間，為此我的MBR重啟了一次強制清空了swap空間, 實際表現會更加顯著
因為文件依賴於瀏覽器的耗時，而瀏覽器需要串列請求依賴，因此耗時會更加長
但實際使用中使用snowpack會更加優秀。因為其相比webpack會大大節約電腦資源。在webpack編譯時會佔用大量的電腦資源，會影響到其他操作
TRPG Engine 算是非常經典的 Webpack 應用了, 使用了各種Loader。光通用配置就有250+行，各種優化配置，各種 alias。等等長時間迭代積攢下來的配置，因此毫不意外的會遇到很多問題與坑。
以下是我遇到的問題與解決方案:
Snowpack雖然作為一個新興的打包工具，目前尚不是非常完善, 功能也沒有webpack這樣豐富與齊全。但是它的新的打包設計對於有一定規模的前端應用還是非常優秀的。能極大提升開發效率。不失為一種好的解決方案。當然最後輸出還是需要使用webpack對其進行一定的優化，畢竟原生的mole支持目前瀏覽器的支持度還沒有達到覆蓋一個理想的地步 https://caniuse.com/es6-mole
最後這是我最後提交的 pr
④ webpack-打包優化方案
分析打包文件
要優化，先分析。我們先要知道到底是哪裡拖慢我們的打包速度呢？
可以利用 webpack-bundle-analyzer 插件來分析我們打包後生成的文件
修改 webpack.prod.conf.js 文件
simple-progress-webpack-plugin 可以顯示打包百分比
修改 webpack.prod.conf.js 文件
效果如下：
資源與依賴包的控制
通過上面進度可以看到，打包過程中，卡頓在壓縮的地方過長，當項目越來越臃腫的時候，我們要需要對項目靜態資源以及依賴包進行整理，
項目裡面使用 ElementUI 和 Echarts 都是全部引用掛在 Vue.prototype 上，現都改為按需引用。
預處理各種文件時指定匹配目錄後， webpack 解析文件時就不會循環查找其他目錄，加快解析速度。
webpack 執行預處理文件時單線程的，我們可以使用 happypack 來多線程處理文件。
修改 webpack.base.js 文件
babel-plugin-dynamic-import-node 插件是使 import() 替換成 require 編譯
修改 .babelrc 文件
注意 ：使用插件 build 後沒有 chunk files 文件。
通過 DllPlugin 插件分離出第三方包
使用 add-asset-html-webpack-plugin 動態添加 dll.js 到 html 。
需要注意
項目經過以上優化，打包從 30 分鍾，到 2 分鍾不到，整體還有優化空間，可以使用其他 cdn 等優化方式。
⑤ 前端構建工具webpack有什麼缺陷
配置多入口時，沒有glob的方式，需要額外處理。
目錄結構復雜時，file-loder裡面的path功能太弱，很多時候無法自定義構建後的目錄結構，只能放在一個目錄下。
源碼比較復雜，遇到問題看源碼，要花很長時間。
如果沒有 babel， webpack 對 ES2015+ 的語法是不接受的，會提示用指定 loader。這意味著，在支持部分 ES2015 語法的 firefox 與 chrome 瀏覽器中能直接跑的代碼，無法用 webpack 編譯。
⑥ 我們還能在哪些方面進行webpack性能優化
Bigo前端組計算平台前端組基於amis框架，參考之前的文章：https%3A%2F%2Fgithub.com%2Fbigo-frontend%2Fblog%2Fissues%2F17 ；有很好的研發效率提升，但是構建速度卻很慢，亟需進行優化。優化之後達到了將webpack構建速度提升80%左右的一個成績，以下是優化前後的對比
團隊做了3件事情來達到這樣的一個效果：
基於這次優化做了功課，看了一些資料，看看還有哪些可以優化的地方。
官網的定義：
webpack is a static mole bundler for modern JavaScript applications. When webpack processes your application, it internally builds a dependency graph which maps every mole your project needs and generates one or more bundles.
也就是說 webpack 是一個用於現代 JavaScript 應用程序的靜態模塊打包工具，從入口出發，找到入口文件所有的依賴，生成瀏覽器可以用的bundle文件。webpack的出現使得前端的工程化更加地豐富。從webpack在2013的第一次release(v1.0.0-beta2)開始，至今已經有8、9年的 歷史 了，是一個相當成熟的工具，其生態也比較完善，所以前端圈用webpack也是非常地廣泛。
盡量用較新的版本，新版本相較之前都會有一定的性能提升和優化，包括Node和Webpack。要注意的是 Node.js v8.9.10 - v9.11.1 ES6的 Set 和 Map 會有性能回退問題，現在LTS的node已經是 v14.16.0 ，所以假設 Node 版本已經較新，並且用的是 WP4 ( webpack4 )。目前還不建議對求穩的或者已經很龐大的項目立即升級到 WP5 ，其一是因為webpack生態裡面並不一定所有的插件都能跟的上最新的版本，可能會出現兼容性的問題；其二由於webpack5還並未被廣泛地應用，到新版本的穩定和成熟還是需要一定的時間，為避免不必要的bug，建議暫時使用 webpack4 。
對於開發者來說，每次在build的時候不希望花費較長的時間，優化構建速度能夠減少開發成本；對於用戶而言，優化bundle文件的數量和大小能減少用戶的流失率，提升用戶體驗。所以webpack的性能優化是一個非常關鍵的技術手段。
webpack構建大概可分為 loader解析 -> 依賴搜索 -> 打包 等三個階段，就這三個階段我們分別展開闡述如何去優化。
loader解析：
依賴搜索：
打包: Smaller = Faster
當然需要在 index.html 裡面引入cdn依賴，否則在runtime無法找到相應的模塊： 。
開發環境* *：** 同樣地，生產環境有些配置也不適用於開發環境，比如 TerserPlugin 就不需要，因為在開發環境中壓縮代碼是沒有意義的；devTools的最佳實踐是 eval-cheap-mole-source-map ，我現在的項目比較輕量，但是也能看出對比：
雖然是不到1000ms的差距，蒼蠅肉也是肉不是？而且將來代碼量越來越龐大的時候，差距就更明顯了。
當然還有其他的可以優化的方法，比如使用ES mole，能更好地利用webpack的tree shaking功能；Dll，為更改不頻繁的代碼生成單獨的編譯結果，但卻是一個配置比較復雜的過程；還有對圖片的壓縮等等。以上是對於webpack4性能優化基本的配置，期待webpack5成熟穩定的那一天。
⑦ vue編譯打包速度優化
1、首先在config文件夾下配置webpack.dll.config.js(內容如下)，要打包的模塊的數組可以將一些較大的依賴放進vendor中
2、在package.json的scripts加上
3、運行npm run dll就可以生成vendor-manifest.json和vendor.dll.js
4、然後在index.html中引入vendor.dll.js
然後就可以正常的進行編譯打包，會發現將更多的依賴放到vendor，打包速度越快
優化前
優化後
大概平均可以節省三分之一的時間。參考 webpack中文網