1. 速度優化
平常開發打包配置你們都是習慣用腳手架等的默認配置，沒問題，沒毛病，跑的好好的，就沒這麼在乎。對於一些強迫症的患者，仍是會有點不爽的， 好比速度，好比最終打包出來的資源大小等等。
1.1 本地構建或者服務端構建
1.1.1 本地構建
開發完後本地構建，而後經過push到cnd同步資源。多是傳統你們喜歡作的思路，沒毛病，也挺好用的。
不足點：加劇了倉庫的體積，對於倉庫中的語義化的npm包，本地構建不能實時享受到包的更新。
優勢： 適合於多人項目合做初期，或者依賴的一個三方包也處於一個不斷迭代的過程，每一個人開發的過程當中僅僅打包本身的頁面，互相不干擾
1.1.2 服務端構建
服務端構建，大體就是當資源push的時候，會在一臺構建機器上面跑相似ci的服務，同時也會有打包的服務
優缺點基本就是本地的相反，可是仍是比較推薦這樣的方案
1.2 如何來優化
1.2.1 配置差別化
粗暴點其實你們可能但願這個配置能夠自動化生成，並且能夠僅有一份來作，思路是沒錯，可是其實應該作一些區分
|
功能
|
本地開發
|
線上發佈
|
|
壓縮代碼
|
須要
|
|
|
babel-polyfill
|
通常不須要
|
看業務需求
|
|
分離樣式
|
須要
|
|
|
刪除console.log
|
須要
|
|
|
css Prefix
|
須要
|
|
|
OccurrenceOrderPlugin
|
須要
|
|
|
DedupePlugin
|
須要
|
|
|
Babel present轉碼
|
須要
|
其實比較合理的方式應該是用環境變量來區分進行不一樣環境下不一樣的配置，ps：設置環境變量爲了在window兼容，可使用cross-env 來設置
以上的對比沒有進行測試，感興趣的同窗能夠試試看，在老的基礎上修改會有多少的優化。
總結起來就是本地開發只求速度快，能少處理一點是一點
1.2.2 常見方式
能夠在社區中看到不少相關相似的文章來作webpack的優化，各類各樣的提速，可能都知道，可是懶得作，但其實一旦完成後，帶來的受益是巨大的。
externals
這多是最暴力最提速的方法之一，把其中的一些庫從中忽略掉，若是extern react了，須要注意的是最好把相關的一些react-addons-transition-group也給extern掉，不然有可能會出現依然打入多份react的問題，由於react-addons-transition-group這樣的包裏面代碼是相似以下方式，externals並不能排除
module.exports = require('react/lib/ReactTransitionGroup');
Dll
將一些可預見性的庫從中抽離，預打包，能夠極大的提速，當時仍是有蠻多須要注意的，好比一樣的包最好全局只有一份，預打包後不能享受到語義化版本的資源跟新，須要結合實際問題來看是否須要。
HappyPack
經常使用套路加速
const os = require('os');
HappyPack.ThreadPool({size: os.cpus().length })
一些配置
設置一些alias，同時能夠適當設置一些loaders中的exclude等
設置css-loader版本號
提速特別明顯
"css-loader": "^0.14.5",
替換scss-loader 爲fast-sass-loader
相比起來比scss-loader速度更快
不用webpack自帶的uglfiyJS
用自帶的uglfiyJS來作壓縮速度比較慢，這邊有倆思路，但原理應該是同樣的
-
造個新輪子多核並行去壓縮js和css
這個方案優化通常來講能夠提速一半左右
js和scss的分離
這個能夠優化本地開發過程當中的rebuild速度，儘可能讓scss文件和js文件分離，若是使用了一些ui庫，能夠引用UI庫的css文件，而不是scss文件，省去每次的scss build過程
1.3 其餘
-
對於打包webpack多是一個功能大而全的工具，除此以外還有不少相似於rollup或者是browserify，要看具體場景來使用，殺雞可能選個更合適的刀會更好，不要盲目選擇都是用一把刀。後續待嘗試後詳細再補相關的一些其餘打包方案。
-
優化永無止境
2. 代碼優化
2.1 精簡node_modules
如今開發基本都是使用npm或者yarns進行依賴管理，隨便引入幾個依賴就會使得最終打包的結構臃腫，再加上開發者可能對依賴的包並無特別統一管理，須要什麼就引入什麼，不會去關心互相之間的關係。
上圖僅僅是說明node_modules管理的時候出現的包的量一個圖，能夠說是很是的形象。
圖片來自文章What’s really wrong with node_modules and why this is your fault，文章推薦一看
注：npm包開發者應該保證包裏面僅只有須要的代碼，好比測試等等的資源最好都忽略掉，這樣也能夠省去很多開支，細節後續會整理一篇新的文章。
2.1.1 方法1：一樣功能使用一樣的包
多人開發常會遇到使用三方庫，部分人使用deep-extend，可是後面可能又有人用lodash，這樣一來一回，會出現一樣功能的包會引用多個的問題。對於這個狀況不會致使bug，可是會形成node_modules增多且package.json依賴混亂，固然代碼大小也會有相應的損失。
解決方式
查看倉庫的package.json，好比
{
"deep-extend": "^0.4.1",
"lodash.clonedeep": "^4.5.0",
}
如上倆個庫都是想作深拷貝，能夠選擇只使用其一便可，推薦
2.1.2 方法2：同一個包儘可能不存在多個版本
大部分狀況這樣僅只會加劇代碼的體積等，可是在少數的場景下，好比使用了前端組件庫；
舉個例子，項目中依賴了倆組件A和B，A依賴了某UI庫C的1.0.0的input，而B依賴了C中的2.0.0的input，最終頁面上會同時存在倆版本的input，這裏存在一個隱患（若是倆組件有Dom節點結構調整發生樣式變化，這個時候不管是使用1.0.0或者是2.0.0的樣式其實都不合適），因此這個問題也須要多關注的，特別是前端的UI庫，最好習慣性的排查下較爲好。必須最好作下
解決方式
打開chrome調試工具，查看node_modules，對於UI的庫，仔細翻翻，不能有多版本的庫，對於其餘庫則能夠佛系排查；若是發現某個庫A出現了屢次，可使用npm ls A來查看是在什麼地方屢次引用到了，而後再定位到具體細節的包查看
2.1.3 方法3：分析代碼依賴
使用webpack的使用BundleAnalyzerPlugin或者是用自帶的功能輸出json，進行分析，排查爲何最後輸出的資源這麼大的緣由
2.2 抽離公用資源
比較適合那些整站的開發，將各個頁面公用的資源抽離出來，這樣在頁面的訪問過程當中瀏覽器能夠很好的將這些通用資源緩存，相似使用dll存在本地工程中，還可使得打包加速，下面以dll爲例
作法
-
配置好項目所要打的dll資源，通常選擇的是一些三方的庫，具體看項目的需求
-
預先打好dll的資源放到項目的某個自定目錄中（甚至能夠直接打成生產環境的版本省去後續的壓縮）
-
本地構建或者服務端構建任務結束後，將打好的dll資源拷貝到build目錄下面
注意點
-
若是使用服務端構建請務必保持本地的npm版本和服務端構建上面的版本一致，不一樣的npm的版本可能會致使manifest.json的裏面內容不一致，由於dll存的是路徑
-
最好解決下同一個庫多版本的問題，不然dll中就會打進去多版本的庫，由於dll存路徑不一樣的版本的版本號是不一致的
2.3 其餘
2.3.1 使用babel-preset-env
官方也是推薦使用它來代替babel-preset-2015，根據業務所須要適配的瀏覽器去選擇合適的，不然使用多餘的轉碼會是的代碼轉碼後更大，同時對於browsers的設置，也能夠跟postCss進行統一
2.3.2 區分好大包小包的問題
一些組件庫或者是lodash
import { isEmpty } from 'lodash';
import isEmpty from 'lodash/isEmpty';
所產生的結果是不同的。除非使用一個轉碼的工具來支持；vscode用戶建議裝一個
Import Cost
2.3.3 升級打包工具webpack
升級到webpack3，有tree shaking、Scope Hoisting都對代碼有着不錯的優化
2.3.4 優化樣式
-
prefix這類的工做交給postCss來完成，一樣是根據業務的需求去作相關的prefix的處理，很少很多
-
精簡樣式，去除不必的樣式