最近接手了一個維護了三年的 React 老項目用戶反饋首屏白屏?xí)r間越來越離譜我隨手 build 一次產(chǎn)物里光 JS 就有接近 6MB。團隊之前一直用換個網(wǎng)絡(luò)環(huán)境試試來掩蓋問題直到要發(fā)新版本連本地開發(fā)都明顯卡頓這才決定認真做一次打包優(yōu)化。整個分析和動手的過程核心工具就是 webpack-bundle-analyzer前后花了一周多時間產(chǎn)物體積降了約 65%首屏加載從 4 秒多壓到了 1.8 秒左右。這篇文章把我這次的完整思路、操作步驟和踩過的坑記錄下來如果你手上也有一個能跑但越來越慢的 React 老項目正打算做打包優(yōu)化可以直接照著這條路線走。1. 老項目動刀之前的三個準備工作先看清現(xiàn)狀再想怎么優(yōu)化很多同學(xué)拿到老項目就直接裝 webpack-bundle-analyzer、生成個報告然后對著報告一頓亂拆拆完發(fā)現(xiàn)構(gòu)建報錯、線上白屏、緩存全失效。我這次學(xué)乖了動手前先做了三件事這幾步幾乎決定了后續(xù)優(yōu)化能不能順利落地。1.1 鎖定項目當前的構(gòu)建工具鏈版本老項目最麻煩的地方在于你不知道它在哪一年突然停更過。所以第一步不是裝插件而是先確認 webpack 和 React 的版本這兩個版本直接決定你能用哪些優(yōu)化手段。我一般這樣排查看package.json里的devDependencies確認webpack主版本執(zhí)行webpack --version確認命令行實際使用的版本在package.json里確認react和react-dom版本這關(guān)系到能不能用React.lazy做路由懶加載檢查 webpack 配置里有沒有DllPlugin、CommonsChunkPlugin這類歷史遺留方案。這里有個容易忽略的點webpack 3 時代流行的CommonsChunkPlugin在 webpack 4 里已經(jīng)廢掉了如果你項目里還有這個配置同時又想用optimization.splitChunks運行時會有沖突或者直接報錯。我接手這個項目時配置文件里就同時存在CommonsChunkPlugin和一堆手寫的externals這些都是早年用 CDN 方式引第三方庫留下的需要先理清楚哪些還生效哪些其實已經(jīng)是死代碼。另外React 版本決定了懶加載方案。React 16.6 之前沒有React.lazy只能用react-loadable或者自己寫高階組件做異步加載。我的項目是 React 16.8后來用React.lazy Suspense比較順。如果你手里的老項目還在 React 15.x別急著抄后面的代碼得先解決 React 版本升級或者改用react-loadable。1.2 建立優(yōu)化前的數(shù)據(jù)基線沒有基線后面所有優(yōu)化都沒有說服力第二件事是在任何優(yōu)化動作之前把優(yōu)化前的各項數(shù)據(jù)記錄下來。這不是走形式而是整個優(yōu)化工程里最重要的參照物。沒有基線你拆完包之后說感覺快了很多那跟換個網(wǎng)絡(luò)環(huán)境試試有什么區(qū)別我用 Chrome DevTools 調(diào)成 Slow 3G 網(wǎng)絡(luò)用無痕窗口打開線上頁面記錄以下幾項指標記錄值說明首屏請求的 JS 資源總大小通過 Network 面板的 Transfer Size 合計這是用戶真實下載的字節(jié)數(shù)首屏請求數(shù)Network 面板統(tǒng)計老項目常見二三十個請求DOMContentLoaded 時間Performance 面板粗略反映 HTML腳本執(zhí)行完的時間FCP首次內(nèi)容繪制Lighthouse 或 Performance用戶感知到頁面有東西了的時刻構(gòu)建產(chǎn)物體積總和webpack --profile或 build 輸出本地產(chǎn)物總大小我當時記錄的基線數(shù)據(jù)是這樣的首屏 JS 資源 transfer 大小約 1.9MBgzip 后請求數(shù) 27 個FCP 在 Slow 3G 下是 4.2 秒。這些數(shù)字寫下來之后后面每做一步優(yōu)化都可以對照著看是否真的有效避免自我感覺良好。這里要額外提醒一句測量工具本身會帶來干擾。比如 Chrome DevTools 的 Network 面板如果開著緩存禁用測出來的數(shù)字會偏大。建議統(tǒng)一用無痕窗口并且固定設(shè)備模擬檔位保證前后對比在同一個環(huán)境下進行。1.3 別急著清依賴先整體過一遍 package.json 的重復(fù)依賴老項目的依賴幾乎都是能用就行堆出來的。我在優(yōu)化前先執(zhí)行了npm ls --depth0和npm ls lodash發(fā)現(xiàn)項目里同時存在lodash和lodash-es還有兩套版本相差很大的moment一個是業(yè)務(wù)代碼直接用另一個是被某個內(nèi)部組件庫間接依賴的。這種重復(fù)依賴如果不提前發(fā)現(xiàn)優(yōu)化到一半很容易被為什么拆了這個庫包還是這么大卡住。這一步不需要把依賴全部理清但至少要回答三個問題項目里有沒有同名不同版本的庫有沒有功能重疊的庫moment和dayjs同時存在有沒有通過externals從 CDN 引入的庫這三個問題的答案會直接影響后面 splitChunks 的 cacheGroups 怎么設(shè)計。2. 接入 webpack-bundle-analyzer兩種方式各有利弊工具接入本身不難難的是選對方式。我在這個項目里兩種方式都試過一種是在 webpack 配置里直接掛插件另一種是用stats.json配合命令行獨立分析。下面把細節(jié)和適用場景都講清楚。2.1 方式一作為 webpack 插件集成構(gòu)建完自動打開報告最直接的方式就是在 webpack 配置文件里加一個插件實例。我通常不會直接寫死在生產(chǎn)配置里而是用一個環(huán)境變量控制避免團隊每次構(gòu)建都彈出瀏覽器窗口。const { BundleAnalyzerPlugin } require(webpack-bundle-analyzer); module.exports { // ... 其他配置 plugins: [ process.env.ANALYZE ? new BundleAnalyzerPlugin({ analyzerMode: server, // server 模式會啟動本地服務(wù)并自動打開瀏覽器 analyzerHost: 127.0.0.1, analyzerPort: 8888, reportFilename: bundle-report.html, openAnalyzer: true, generateStatsFile: false, // 如果只需要報告不必生成 stats.json }) : null, ].filter(Boolean), };然后在package.json里加一條腳本{ scripts: { build:analyze: cross-env ANALYZE1 webpack --config webpack.prod.config.js } }這樣執(zhí)行npm run build:analyze就會啟動一個本地服務(wù)瀏覽器自動打開127.0.0.1:8888展示可視化的依賴樹形圖treemap。每個方塊代表一個模塊方塊越大說明該模塊占用的體積越大顏色深淺則代表是否為 gzip 壓縮后的大小。插件方式的好處是集成簡單適合團隊里所有人都能一鍵跑分析的場景。但它的缺點也很明顯BundleAnalyzerPlugin會作為 webpack 插件參與構(gòu)建雖然不影響產(chǎn)物但會在構(gòu)建過程中增加額外的統(tǒng)計開銷構(gòu)建時間會長一些。而且如果 webpack 配置特別復(fù)雜比如有多個環(huán)境配置文件你需要確保插件加在了正確的那個配置文件里。2.2 方式二用 stats.json 配合命令行不污染業(yè)務(wù)配置第二種方式是我比較推薦的尤其適合老項目——因為它完全不動 webpack 配置。webpack 本身就支持導(dǎo)出整個構(gòu)建過程的 stats 信息導(dǎo)出成 JSON 文件后用webpack-bundle-analyzer這個命令行工具直接分析。# 先構(gòu)建并導(dǎo)出 stats 數(shù)據(jù) webpack --config webpack.prod.config.js --json --profile stats.json # 再啟動分析器 npx webpack-bundle-analyzer stats.json這種方式有幾個實際好處不需要在項目代碼里引入任何插件不影響正常構(gòu)建stats.json是構(gòu)建的完整快照包含模塊依賴、體積、耗時等信息后續(xù)做對比分析時可以直接復(fù)用可以配合 CI 流程把每次構(gòu)建的stats.json歸檔形成體積趨勢圖。要注意的是--json輸出的文件很大我這個項目大概 40 多 MB所以用完記得從項目目錄里刪掉或者用.gitignore排除。另外如果.babelrc或tsconfig里配置了緩存--json導(dǎo)出的是實際構(gòu)建結(jié)果不受緩存影響這點可以放心。2.3 拿到報告之后先看這四個地方再動手報告生成后很多人的第一反應(yīng)是盯著最顯眼的那個大色塊準備開始拆它。我的建議是先快速過四個關(guān)鍵點這樣你腦子里對項目整體的構(gòu)成能有一個完整的圖景看parsed size還是gzip size。雙擊某個色塊可以切換展示模式。parsed size是未壓縮的原始大小gzip size是壓縮后的傳輸大小。判斷是否值得優(yōu)化時應(yīng)該以 gzip 為主要參考因為線上服務(wù)器通常開了 gzip?？慈肟?chunk 的大小分布。把報告左側(cè)的 chunk 列表展開關(guān)注哪些 chunk 是首屏加載時就要請求的entry chunk哪些是路由懶加載之后才會請求的async chunk。看有沒有異常大的單模塊。有些庫本身不算大但因為引入了所有語言包、所有主題體積會成倍膨脹這類問題非常適合定向處理?？粗貜?fù)模塊。如果同一個庫名出現(xiàn)在多個 chunk 里說明業(yè)務(wù)代碼對它的引用方式有問題可能是按需引入沒生效也可能是 cacheGroups 沒有正確聚合。我當時看完報告最直觀的感受就是這個項目不是某一個庫太大而是每一個庫都沒被好好控制。這也為后面的優(yōu)化定下了基調(diào)——不是做一兩個大改動而是系統(tǒng)性地把每一類依賴都重新過一遍。3. 報告暴露出來的問題React 老項目的五個典型通病我的項目報告里vendor.js這一個 chunk 的 parsed size 就達到了 4.6MB。如果你現(xiàn)在也正對著一份類似的報告發(fā)愁不用慌下面這五個問題在 React 老項目里幾乎是標配而且都有成熟的解法。3.1 全量引入 UI 組件庫和圖表庫我的項目里antd的 parsed size 是 1.8MB 左右。為什么這么大因為業(yè)務(wù)代碼里寫的是import { Button } from antd看似是按需引入但如果 babel 沒有配babel-plugin-import這條語句最終會被編譯成var Button require(antd)也就是把整個antd全部加載進來。本質(zhì)原因就是import { Button } from antd這個語法本身具備 tree-shaking 的可能但前提是antd的 package.json 里配置了sideEffects: false或module入口而且 babel 轉(zhuǎn)譯時不能把模塊系統(tǒng)直接轉(zhuǎn)成 CommonJS。圖表庫也是這樣。項目里用了echarts業(yè)務(wù)代碼是import * as echarts from echarts這等于把 echarts 全部圖表類型、渲染器和組件都帶上了parsed size 超過 1MB。正確做法是echarts/core按需引入需要的圖表和渲染器這個在后面 4.3 節(jié)詳細講。3.2 moment.js 把所有語言包都打進來了moment是 React 老項目里最典型的體積元兇之一。默認情況下moment會打包全部 locale 語言文件即便你只需要中文。報告里你會看到moment的 parsed size 超過 700KB但其中真正用的只有一小部分。專門的 locale 文件全部打進包里屬于典型的用不到的體積。這類庫的優(yōu)化思路有兩個方向用IgnorePlugin剔除 locale 文件或者干脆換dayjs這種體積小一個數(shù)量級的替代庫。我最后選擇了后者細節(jié)在后面單獨說。3.3 lodash 全量引入導(dǎo)致 tree-shaking 失效老項目里幾乎不可能沒有l(wèi)odash。我的項目里lodash的 parsed size 是 400KB 左右原因是大量代碼里直接import _ from lodash。lodash主包是 CommonJS 格式現(xiàn)代打包工具很難對它做 tree-shaking所以最佳習(xí)慣是改為import debounce from lodash/debounce這樣的按需路徑引入或者配置babel-plugin-lodash自動轉(zhuǎn)換。如果你在報告里看到lodash-es而不是lodash那又是另一種情況lodash-es是 ES module 版本理論上可以被 tree-shaking但前提是你的業(yè)務(wù)代碼沒有被 babel 轉(zhuǎn)成 CommonJS。很多老項目的.babelrc里配置了babel/preset-env默認會把 ES module 轉(zhuǎn)成 CommonJS這會導(dǎo)致lodash-es的 tree-shaking 優(yōu)勢完全喪失。所以排查時不能只看庫本身還要看 babel 的配置鏈。3.4 polyfill 全量引入導(dǎo)致基礎(chǔ)工具函數(shù)被重復(fù)打包React 老項目里babel/polyfill或core-js全量引入的情況非常多。babel/polyfill本質(zhì)上是core-js和regenerator-runtime的合集全量引入會讓每個用到新 API 的頁面都背上幾百 KB 的 polyfill 成本。正確的做法是按需要的特性引入core-js中的具體模塊或者用babel/preset-env配合useBuiltIns: usage實現(xiàn)按需 polyfill。老項目之所以容易踩這個坑是因為當年寫import babel/polyfill的時候覺得省事后面就再也沒人記得去改。同時如果 babel 配置里沒有采用babel/plugin-transform-runtimebabel 轉(zhuǎn)譯時會在每個文件里都內(nèi)聯(lián)一部分輔助函數(shù)造成大量重復(fù)。這個在報告里不容易一眼看到因為每個重復(fù)模塊都很小但積少成多后總效果非常明顯。3.5 所有的路由頁面都打包進了首屏入口 chunkReact 老項目普遍沒有做路由懶加載。如果你的 App 里有十幾個路由頁面它們會全部打包進一個入口 chunk 里用戶訪問首頁時所有頁面的代碼都要先下載完。報告里體現(xiàn)為入口 chunk 特別大async chunk 數(shù)目為零。這是優(yōu)化優(yōu)先級最高的一項因為它的收益幾乎立竿見影。4. 按優(yōu)先級動手我實際執(zhí)行的五步優(yōu)化下面按我執(zhí)行的順序把每一步的具體操作和理由講清楚。這個順序不是隨便排的每一步都會影響下一步的方案選擇所以建議大家按順序來。4.1 第一步用 splitChunks 把 node_modules 里的公共依賴統(tǒng)一抽離這是 webpack 4 之后最基礎(chǔ)、也是收益最大的一步。把第三方依賴統(tǒng)一抽成獨立的 chunk一方面減少了模塊在多個 chunk 之間的重復(fù)打包另一方面利用瀏覽器緩存讓用戶升級業(yè)務(wù)代碼時不用重新下載體積龐大的第三方庫。我當時的 splitChunks 配置大致是這樣optimization: { splitChunks: { chunks: all, maxInitialRequests: 4, maxAsyncRequests: 6, cacheGroups: { vendors: { test: /[\\/]node_modules[\\/]/, priority: -10, name: vendors }, antd: { test: /[\\/]node_modules[\\/]antd[\\/]/, priority: 10, name: antd }, echarts: { test: /[\\/]node_modules[\\/]echarts[\\/]/, priority: 10, name: echarts }, common: { minChunks: 2, minSize: 30000, priority: -20, name: common } } } }這里有幾個細節(jié)值得展開。chunks: all表示同步引入和異步引入的代碼都參與拆包。如果你只寫chunks: initial那么動態(tài)import()引入的模塊不會被拆分可能導(dǎo)致懶加載的 chunk 里又重復(fù)打了一遍 React 或 antd。這個參數(shù)是最容易配錯的點。priority決定多個 cacheGroup 匹配時誰優(yōu)先。antd 和 echarts 的體積大我希望它們能單獨成 chunk這樣它們的 hash 只會在自身內(nèi)容變化時才變化業(yè)務(wù)代碼更新不會導(dǎo)致這兩個大 chunk 重新下載。如果不給它們單獨分組的 priority它們會被并進vendors那樣雖然拆包總數(shù)少但 antd 一更新整個 vendors 都失效緩存利用率會低很多。name字段一定要固定。webpack 4 默認會給自動生成的 vendor chunk 按數(shù)字編號命名當依賴順序變化時編號會漂移導(dǎo)致 chunk hash 大面積變化這是明明沒改代碼hash 卻全變了的經(jīng)典原因。我踩過這個坑后所有 cacheGroup 都顯式指定 name。如果你是從 webpack 3 升級上來一定要先刪掉原來配置里的CommonsChunkPlugin否則它和splitChunks會同時生效產(chǎn)生大量重復(fù)的小 chunk。這一步做完我的vendor.js從 4.6MB 拆成了antd、echarts、vendors三個 chunk加起來反而比原來小了不少因為里面的重復(fù)模塊被剝離了。4.2 第二步路由級代碼分割讓首屏只加載當前頁面需要的代碼拆完公共依賴后入口 chunk 依然很大因為十幾個路由頁面全都打包在里面。這一步的目標是把所有頁面的代碼變成當前頁面的代碼 運行時按需加載的代碼。如果你的 React 版本在 16.6 以上直接用React.lazy加Suspenseimport { lazy, Suspense } from react; import { BrowserRouter as Router, Route, Switch } from react-router-dom; import Loading from ./components/Loading; const Dashboard lazy(() import(/* webpackChunkName: dashboard */ ./pages/Dashboard)); const UserManage lazy(() import(/* webpackChunkName: user */ ./pages/UserManage)); const Settings lazy(() import(/* webpackChunkName: settings */ ./pages/Settings)); function App() { return ( Router Suspense fallback{Loading /} Switch Route exact path/ component{Dashboard} / Route path/user component{UserManage} / Route path/settings component{Settings} / /Switch /Suspense /Router ); } export default App;關(guān)鍵點在于import(/* webpackChunkName: dashboard */ ./pages/Dashboard)里的webpackChunkName注釋它給動態(tài)生成的 chunk 起了一個有意義的文件名否則你會在報告里看到一堆0.js、1.js完全沒法定位是哪個頁面。如果你項目還在 React 15.x用react-loadableimport Loadable from react-loadable; const Dashboard Loadable({ loader: () import(./pages/Dashboard), loading: Loading, delay: 200, });這一步做完優(yōu)化效果非常直觀。首屏入口 chunk 從一個 近5MB 的龐然大物變成了只包含 React 運行時、路由、布局框架等公共代碼的 200KB 左右 chunk。每個路由頁面獨立成 chunk用戶訪問哪個頁面就加載哪個頁面的代碼。這里有一個反直覺的坑不要對首屏默認進入的那個頁面做懶加載。如果首頁本身就是落地頁把首頁也做成動態(tài) import首屏?xí)喟l(fā)起一個 HTTP 請求反而增加延遲。我在項目里把登錄頁和首頁放在了入口 chunk 里其余頁面懶加載。4.3 第三步UI 庫和圖表庫按需引入讓 tree-shaking 真正生效路由拆分解決了整體過大的問題接下來要解決單個庫過大的問題。先是 antd配置babel-plugin-import后import { Button } from antd會被自動轉(zhuǎn)換為import Button from antd/es/button連同樣式也會按需加載。.babelrc里這樣配{ presets: [babel/preset-react, [babel/preset-env, { modules: false }]], plugins: [ [import, { libraryName: antd, libraryDirectory: es, style: css }] ] }注意preset-env里的modules: false這個配置讓 babel 保留 ES module 語法不轉(zhuǎn)成 CommonJS這樣打包工具才能在后續(xù)做 tree-shaking。如果你項目里同時用了 TSbabel/preset-typescript也要注意同樣的設(shè)置。style: css表示按需加載組件對應(yīng)的 css 文件。如果你的項目用的是 less 定制主題可以把style改成trueantd 會加載 less 文件。這個改動需要注意全局樣式覆蓋如果你之前靠antd/dist/antd.css引入的全局 reset 樣式改成按需后要在公共入口處手動引一次。echarts 的處理也類似但思路不同。echarts 5 開始支持echarts/core方式按需注冊import * as echarts from echarts/core; import { BarChart, LineChart } from echarts/charts; import { GridComponent, TooltipComponent } from echarts/components; import { CanvasRenderer } from echarts/renderers; echarts.use([BarChart, LineChart, GridComponent, TooltipComponent, CanvasRenderer]);這一步實際上是把 echarts 從一個 1MB 的大包縮小到只包含你用到的那幾種圖表。我項目里主要用柱狀圖和折線圖配完工具提示和網(wǎng)格gzip 后只有原來的三分之一左右。lodash 的處理我選了最保守的方式不換庫直接把全量引入改成按路徑引入。import _ from lodash改成import debounce from lodash/debounce。如果你的代碼里用了大量 lodash API可以在 babel 里加babel-plugin-lodash自動轉(zhuǎn)換省得手動改幾十個文件。但是要留意這個插件對lodash-es和 CommonJS 混用的情況處理得不夠理想所以我最后還是手動改了一部分關(guān)鍵模塊。4.4 第四步對 moment.js 這種頑固分子下手先裁剪再替換moment 的問題前面說過了默認打包全部 locale體積大。最省事的操作是先用IgnorePlugin把 locale 文件剔除掉const webpack require(webpack); module.exports { plugins: [ new webpack.IgnorePlugin(/^\.\/locale$/, /moment$/), ], };這個正則的意思是匹配包名以moment開頭、導(dǎo)入路徑是./locale的模塊直接忽略。配置之后 moment 的 parsed size 大概能從 700KB 降到 300KB 左右因為核心庫本身還是保留的。別小看這個正則IgnorePlugin的resourceRegExp和contextRegExp兩個參數(shù)的順序很容易寫反寫反后可能導(dǎo)致整個 moment 都被忽略運行時報錯。如果你希望體積縮得更狠就把 moment 整體替換成 dayjs。dayjs 的核心只有 2KB 左右API 和 moment 高度一致。我的替換步驟是這樣的在package.json里加入dayjs暫時保留 moment先用 webpack alias 把所有import xxx from moment指向 dayjsresolve: { alias: { moment: dayjs, }, },全局搜索業(yè)務(wù)代碼里所有moment用法逐個處理 API 差異最典型的差異是moment().format(YYYY-MM-DD)在兩者中寫法一致moment().startOf(day)在 dayjs 里行為基本一致moment.locale(zh-cn)需要改成import dayjs/locale/zh-cn加上dayjs.locale(zh-cn)moment.isMoment()在 dayjs 里要改成dayjs.isDayjs()。處理完所有業(yè)務(wù)代碼后最后再看報告確認項目里還有沒有其他包比如某個老版本 antd 或業(yè)務(wù)組件庫依賴 moment。我當時發(fā)現(xiàn)一個內(nèi)部統(tǒng)計組件間接依賴了 moment 2.x但它只是用它格式化日期于是我把那個組件也改了。這一步做完moment 相關(guān)體積從 700KB 變成了 dayjs 的 7KB。甚至比很多同學(xué)在第一步做的拆包效果更明顯。4.5 第五步輸出文件加上 ContentHash讓之前拆出來的緩存真正生效前面拆了那么多 chunk如果輸出文件名還是固定的bundle.js那瀏覽器永遠不知道這些文件更新了會一直使用舊緩存。這次優(yōu)化的最后一步就是把輸出文件改成帶內(nèi)容 hash 的形式。output: { filename: [name].[contenthash:8].js, chunkFilename: [name].[contenthash:8].js, },[contenthash]是根據(jù)文件內(nèi)容生成的 hash文件內(nèi)容變化時 hash 才變化。加上這個之后業(yè)務(wù)代碼更新時只有業(yè)務(wù) chunk 的 hash 會變antd、echarts、vendors 這些第三方 chunk 的 hash 保持不變?yōu)g覽器可以直接走緩存。但這里有一個 webpack 4 特有的坑模塊的 id 默認是自增數(shù)字只要新增或刪除一個模塊所有模塊的 id 都可能變化導(dǎo)致許多本來沒變的 chunk 的 hash 跟著變。解決方式是加上optimization.moduleIds: hashed讓模塊 id 基于模塊路徑生成內(nèi)容路徑不變 id 就不變。webpack 5 已經(jīng)默認用deterministic方案不需要手動配。optimization: { moduleIds: hashed, },這個配置本身其實也是優(yōu)化的一部分。很多人只加了[contenthash]卻漏了moduleIds發(fā)現(xiàn) hash 還是到處變以為配置無效其實問題就出在模塊 id 不穩(wěn)定。另外如果服務(wù)器還沒開 gzip這一步建議一并處理。最穩(wěn)妥的方式是讓運維在 Nginx 層開啟 gzip 或 brotli如果不方便改服務(wù)器配置也可以用compression-webpack-plugin在構(gòu)建時直接生成.gz文件讓服務(wù)器直接返回壓縮文件。開啟 gzip 后JS 體積大概能再縮小 60% 到 70%效果非?？捎^。5. 拆包優(yōu)化之后的隱藏坑緩存穩(wěn)定性、請求數(shù)與驗證方式優(yōu)化做完不等于萬事大吉。我這次在收尾階段又踩了幾個坑都是拆包之后才會暴露出來的問題專門寫一節(jié)提醒后來的同學(xué)。5.1 拆包的穩(wěn)定性直接決定緩存命中率拆包方案確定之后最重要的一件事是保證每次構(gòu)建相同的代碼生成相同的 chunk 和 hash。否則哪怕你沒改代碼重新構(gòu)建出來的 hash 也變了緩存全部失效優(yōu)化等于白做。保證穩(wěn)定性的關(guān)鍵有三個cacheGroup 里的name必須顯式指定不要用 webpack 自動生成的數(shù)字編號配置optimization.moduleIds讓模塊 id 穩(wěn)定動態(tài)import()必須在代碼里用靜態(tài)字符串路徑不要用變量拼接路徑否則 webpack 沒法確定 chunk 邊界可能生成不可預(yù)測的 chunk。我建議在優(yōu)化完成后連續(xù)構(gòu)建兩次對比兩次dist目錄里的文件名是否完全一致。如果兩次 hash 不同說明配置里還有不穩(wěn)定因素不要急著上線。5.2 拆得太碎首屏請求數(shù)反而拖累加載拆包有個陷阱不是越細越好。HTTP/1.1 時代瀏覽器對同域名的并發(fā)請求數(shù)限制在 6 個左右如果你把業(yè)務(wù)代碼拆成三十個小 chunk首屏要排隊下載反而更慢。即便現(xiàn)在普遍用 HTTP/2每個請求也有 header 和連接開銷請求數(shù)過多依然會拖慢首屏。我在這個項目里嘗試過把每個頁面里的業(yè)務(wù)模塊進一步拆成細粒度 chunk結(jié)果首屏請求數(shù)從十幾個變成三十幾個FCP 反而從 1.8 秒漲回 2.1 秒。后來我把maxInitialRequests設(shè)置為 4把首頁相關(guān)的幾個核心模塊合并到一個 chunk 里才回到理想狀態(tài)。如果你的服務(wù)器不支持 HTTP/2尤其要注意不要拆太碎。老項目有時還掛著某種內(nèi)網(wǎng)環(huán)境的舊瀏覽器請求并發(fā)限制更嚴格寧可單個 chunk 大一點也別讓首屏請求數(shù)失控。5.3 優(yōu)化效果的驗證同時看體積數(shù)字和真實加載表現(xiàn)最后驗證階段我又把 webpack-bundle-analyzer 生成了一份新的報告和優(yōu)化前的報告對比。同一份stats.json也可以直接復(fù)用跑一次webpack-bundle-analyzer打開舊文件和 新文件看顏色塊的面積變化非常直觀。我優(yōu)化前后的關(guān)鍵數(shù)據(jù)對比項目優(yōu)化前優(yōu)化后總構(gòu)建產(chǎn)物 parsed size約 6.8MB約 2.4MBgzip 后總傳輸體積約 1.9MB約 700KB首屏 chunk 數(shù)量1 個所有頁面都在一起4 個FCPSlow 3G4.2 秒1.8 秒白屏?xí)r間用戶反饋3 秒以上基本感覺不到但是要特別注意構(gòu)建產(chǎn)物小了不一定代表線上真實體驗就快了。還要在線上環(huán)境重新測一遍 FCP、LCP、請求數(shù)用前面同樣的網(wǎng)絡(luò)條件。我見過有同學(xué)本地構(gòu)建產(chǎn)物很小但上線后因為服務(wù)器沒開 gzip、或者某些 chunk 被錯誤的緩存策略緩存了體驗反而更差。所以驗證一定要以真實線上環(huán)境為準?；氐介_頭說的那個問題老項目不是不能優(yōu)化而是要有方法、有順序、有驗證。webpack-bundle-analyzer 的價值在于把我覺得項目很慢變成我知道項目慢在哪個模塊所有決策都建立在數(shù)據(jù)之上。順著報告暴露的問題按順序解決每一步改動都能在下一份報告里看到反饋這才是打包優(yōu)化最踏實的打開方式。最后再分享一個我在收尾時保留的習(xí)慣我把 webpack-bundle-analyzer 接進了 CI 的一個可選任務(wù)每次發(fā)版前指定跑一次報告以 HTML 形式歸檔。幾個月后回頭翻就能看到項目體積的走勢。只要新引入的依賴讓體積明顯反彈下一次報告里立刻能看出來。這種讓數(shù)據(jù)持續(xù)說話的做法比任何一次性的優(yōu)化都更管用。