“首屏加載 3.2 秒”這幾個字擺在我面前的時候產品經理表情是平靜的我心里是拔涼的。當時的頁面不算重但打包出來一個 1.2MB 的整包 JS里面混著編輯器、圖表庫、日期組件首屏用到的其實只占五分之一。整輪優(yōu)化做下來沒上什么奇技淫巧核心思路就一個詞異步加載。把不是首屏必須的東西全部往后挪能晚加載就晚加載能分片加載就分片加載最終首屏壓到 1.1 秒。這篇文章把這些內容整理成一套可以直接抄走的方案覆蓋基礎原理、常見手段、真實改造過程和排錯技巧適合手里有頁面加載慢、白屏時間長、想做性能優(yōu)化又不知道從哪下手的同學。1. 異步加載到底在解決什么問題先不急著上工具把原理層的東西聊透。很多人用了很多年 async、defer、動態(tài) import但你說不清它們到底改變了什么。性能優(yōu)化最怕的就是“照著別人的配置抄了一遍出了問題不知道怎么調”所以這一部分把異步加載的底層邏輯拆開講。1.1 瀏覽器解析 HTML 時的“卡殼”現象瀏覽器從服務器拿到 HTML 文檔之后渲染主線程會從頭到尾掃描并解析它。解析過程中遇到一個普通的script標簽沒有加 async 或 defer瀏覽器會立刻停止解析 HTML先發(fā)送請求把這段腳本下載下來然后執(zhí)行完再繼續(xù)解析后面的內容。這個行為叫“解析阻塞”Parser Blocking。為什么它是性能的大敵因為下載是網絡操作執(zhí)行是 CPU 操作兩個都是耗時大戶。假如你有一個 400KB 的腳本放在head里在 3G 網絡下下載可能需要 2 秒這 2 秒里用戶看到的就是一個白屏頁面連第一行文字都渲染不出來。而頁面需要用戶盡快看到東西每一百毫秒的延遲都會讓用戶覺得“這個網站很慢”?？梢源騻€比方你在廚房里做飯每切一個菜都要停下等幫廚把下一個食材遞到手上而且這個幫廚動作很慢。明明你有五個菜要做大部分時間卻耗在等待上。異步加載想做的事情很簡單——把“等待”從主流程上摘出去讓做菜的流水線不要停。1.2 主線程單線程與渲染阻塞的必然性這里還有一個很多人忽略的問題為什么瀏覽器非要用同步的方式執(zhí)行腳本讓頁面卡住而不是“腳本慢慢下載我先渲染頁面”呢因為 JavaScript 可以修改 DOM 結構比如document.write()可以直接往文檔里寫內容也可以刪除節(jié)點、改樣式。如果瀏覽器一邊解析 HTML 一邊執(zhí)行腳本兩邊同時對 DOM 做操作狀態(tài)就會亂套。所以瀏覽器做了一個硬性規(guī)定解析和腳本執(zhí)行必須互斥主線程一次只能干一件事。這是保證頁面行為一致性的前提犧牲的就是“速度”。理解了這一點你就能明白異步加載的本質它不是把腳本執(zhí)行的耗時抹掉了而是把腳本執(zhí)行的時機調度到“不需要阻塞渲染”的時間點上。比如 defer 會把腳本推遲到整個文檔解析完之后再執(zhí)行這樣首屏文本、圖片可以先出來用戶先看到東西腳本在后臺執(zhí)行再對頁面做增強。這是“感知性能”的巨大勝利。1.3 異步代碼范式的演進從回調到 async/await異步加載不只是“腳本標簽加屬性”做工程化的時候我們經常需要動態(tài)控制腳本的加載時機和依賴關系。這個過程繞不開 JavaScript 異步編程范式的演進簡單捋一遍。最初是純回調。比如動態(tài)加載一個 SDKfunction loadScript(url, callback) { var script document.createElement(script); script.src url; script.onload callback; document.head.appendChild(script); } loadScript(sdk-a.js, function () { loadScript(sdk-b.js, function () { initApp(); }); });代碼不復雜但一旦 SDK 數量變多、依賴層級變深就進入“回調地獄”很難維護。而且并行加載兩個腳本的時候必須手動計數寫起來非常啰嗦。后來有了 Promise配合Promise.all可以實現并行加載并且統(tǒng)一處理結果function loadScript(url) { return new Promise(function (resolve, reject) { var script document.createElement(script); script.src url; script.onload resolve; script.onerror reject; document.head.appendChild(script); }); } Promise.all([loadScript(a.js), loadScript(b.js)]) .then(function () { return loadScript(c.js); }) .then(initApp) .catch(function () { console.error(腳本加載失敗); });再后來就是async/await代碼讀起來跟同步一樣直觀async function init() { await loadScript(a.js); await loadScript(b.js); render(); }這套演進對性能優(yōu)化的意義在于你可以用非常清晰的方式控制“什么時候加載什么資源”而不是依賴文檔里 script 標簽的排列順序。異步加載不是“內容變少了”而是“命令的組織方式更可控了”。2. 常見異步加載方案與選型要點現在到了動手環(huán)節(jié)。異步加載的手段非常多樣每一套都有它的適用場景和坑。這一節(jié)把主流的方案逐一說清楚并用選型視角告訴你在什么情況下選哪一種。2.1 script 標簽的 async 與 defer這是最基礎、也是使用頻率最高的一對屬性。兩者都讓瀏覽器“邊解析 HTML 邊下載腳本”不阻塞解析但執(zhí)行時機差別很大。屬性下載時機執(zhí)行時機順序保證典型場景async邊解析邊下載下載完成后立即執(zhí)行不保證誰先下載完誰先執(zhí)行獨立統(tǒng)計腳本、廣告腳本不依賴其他資源defer邊解析邊下載文檔解析完成后、觸發(fā) DOMContentLoaded 之前按文檔中的順序執(zhí)行需要操作 DOM、依賴執(zhí)行順序的腳本注意幾個容易翻車的點。如果你有兩個腳本b.js 依賴 a.js 里聲明的函數用 async 就可能報錯——因為 a.js 體積大、下載慢b.js 先下載完先執(zhí)行調用一個不存在的函數直接 ReferenceError。defer 就沒這個問題它保證按順序執(zhí)行。另外一個細節(jié)是多腳本場景下 defer 的執(zhí)行順序是文檔順序但它們會在DOMContentLoaded事件之前統(tǒng)一執(zhí)行。意味著你可以在“解析完但還沒觸發(fā)事件”的時候做初始化工作。這類腳本適合放業(yè)務代碼async 腳本適合埋點、監(jiān)控、AB 實驗這類完全獨立、加載完跑一下就不管的東西。2.2 動態(tài)腳本注入與按需加載有些場景下腳本不在 HTML 里而是用戶觸發(fā)某個動作之后才需要。比如用戶點擊“幫助中心”按鈕之后才需要打開客服 SDK用戶把頁面滾動到某個區(qū)塊才需要加載圖表渲染庫。這時候動態(tài)注入腳本是更精準的手段?；A寫法一句話就能概括function loadScript(url) { return new Promise(function (resolve, reject) { var script document.createElement(script); script.src url; script.onload resolve; script.onerror reject; document.head.appendChild(script); }); }實現層面有兩個實際問題值得注意。第一是防重復加載如果用戶反復點擊按鈕腳本會被重復注入浪費流量不說還會帶來重復執(zhí)行副作用。一般用一個 Map 記錄已經加載或正在加載的 URLvar loadingMap {}; function loadScript(url) { if (loadingMap[url]) { return loadingMap[url]; } loadingMap[url] new Promise(function (resolve, reject) { var script document.createElement(script); script.src url; script.onload resolve; script.onerror function () { delete loadingMap[url]; reject(new Error(加載失敗: url)); }; document.head.appendChild(script); }); return loadingMap[url]; }第二是錯誤處理網絡抖動、CDN 掛了都會導致加載失敗如果 Promise 沒有 catch 住控制臺會報 Unhandled Promise Rejection。生產環(huán)境里最好在 catch 里給用戶一個輕提示同時允許重試。2.3 打包器視角代碼分割與動態(tài) import現代前端項目里手動創(chuàng)建 script 標簽已經不多了更主流的是“代碼切割 動態(tài) import”的組合。以 Webpack 或 Vite 為例只要代碼里寫了動態(tài) import打包器就會自動把這個模塊拆成一個獨立的 chunk瀏覽器在運行到 import 語句時才發(fā)起請求。最簡單的例子是路由懶加載。以 Vue 為例const routes [ { path: /detail, component: () import(./views/Detail.vue) } ];React 同類場景用React.lazy配合Suspenseconst Detail React.lazy(() import(./views/Detail));這種做法對首屏最友好的點在于用戶訪問首頁時只加載首頁代碼只有真正跳轉到某個路由時才加載對應的 JS。需要特別注意的是動態(tài) import 返回的是 Promise如果你的頁面里對懶加載組件做了“即時渲染”在 chunk 還沒下載完成時會觸發(fā) Suspense 的 fallback如果 fallback UI 沒寫會直接白屏。JavaScript 里動態(tài) import 的錯誤也需要捕獲特別是懶加載失敗之后不能一點反饋都沒有。2.4 圖片懶加載與預加載的配合圖片是頁面體積的大頭有時候一張高清圖比整個 JS 還大。圖片生性能優(yōu)化最簡單的一條路就是不要一口氣全加載。原生loadinglazy屬性已經不需要任何庫瀏覽器自動判斷圖片進入視口附近才加載兼容性足夠用。不過原生屬性的觸發(fā)時機沒有做精細控制想要“提前一點加載”或者“做骨架占位”用IntersectionObserver更穩(wěn)var observer new IntersectionObserver(function (entries) { entries.forEach(function (entry) { if (entry.isIntersecting) { var img entry.target; img.src img.dataset.src; observer.unobserve(img); } }); }, { rootMargin: 200px 0px }); document.querySelectorAll(img[data-src]).forEach(function (img) { observer.observe(img); });rootMargin 設置成200px 0px表示圖片進入視口下方 200px 范圍時就開始加載這樣用戶滾動到圖片附近時它已經基本加載完不會有明顯的刷新感。預加載preload/prefetch則是異步加載體系里的“先手”link relpreload hrefcritical.css asstyle link relprefetch hrefdetail-page-chunk.jspreload 適合急用資源告訴瀏覽器“你現在就下優(yōu)先級調高”但注意別濫用首屏同時 preload 十幾個資源會讓網絡通道擁擠得不償失。prefetch 則是“如果你有空幫我下載未來會用的資源”行為更溫和適合路由級 chunk。3. 實戰(zhàn)記錄一個 3.2 秒頁面的完整改造原理和方案講了這么多最終還是要落到真實項目里。記錄一個我經手過的典型優(yōu)化把過程和數據都擺出來你可以照著思路復現。3.1 改造前的病灶診斷項目是一個后臺管理系統(tǒng)技術棧是 Vue 2 Webpack入口文件在 main.js 把幾乎所有業(yè)務頁面需要的公共依賴都 import 了一遍再加上全量引入了幾個第三方庫。打包產物是 vendor.js app.js總共 1.2MB未壓縮。在 Chrome DevTools 的 Network 面板里看瀑布圖問題非常直觀HTML 文檔下載只用了 80ms但 vendor.js 下載耗時 904ms執(zhí)行耗時 612msapp.js 下載 486ms執(zhí)行 523ms這兩段 JS 從下載到執(zhí)行拖了 2.5 秒多期間首屏一直白屏加上 CSS 和幾張首屏大圖的加載首屏完全可交互的時間穩(wěn)定在 3.2 秒以上。還有更糟的登錄頁用得極少的地圖組件也在主包里面用戶根本沒打開過相關頁面代價卻是每次進系統(tǒng)都要白下載幾百 KB 代碼。3.2 四步改造路徑第一步是拆包。把第三方依賴拆成 core 和 extras 兩撥。core 只保留 Vue、Vue Router、公共狀態(tài)管理這類任何頁面都必須的東西extras 包括圖表庫、富文本編輯器、地圖 SDK全部改成動態(tài) import。第二步是路由懶加載。系統(tǒng)有登錄、列表、詳情、設置四個主路由每個路由組件改成() import()寫法打包器自動拆成獨立 chunk。改完之后首頁分包從 1.2MB 縮到 260KB這是首屏時間大幅下降最直接的原因。第三步是組件級按需引用。以前為了省事在全局 components 里注冊了一堆 UI 組件現在改成頁面內單獨 import。像日期范圍選擇器這種只有列表頁篩選欄用到的東西再也不用出現在登錄頁的加載鏈路里。第四步是圖片懶加載。首屏之外的輪播圖、長列表封面圖全部加loadinglazy對需要精確控制位置的圖片使用 IntersectionObserver 方案設置 200px 的提前量保證用戶滾動時圖片已經悄悄加載了不會出現“加載一半卡住”的視覺斷層。3.3 優(yōu)化效果與關鍵參數對照改造完成后用同樣的網絡環(huán)境Fast 3G 模擬跑了一遍數據指標改造前改造后首屏完全可交互時間3.2s1.1s首屏 JS 體積未壓縮1.2MB260KBTCP 連接數2312LCP最大內容繪制3.0s1.2sLighthouse 性能分4286其中 LCP 這個指標特別值得關注因為它反映的是“用戶看到主要內容”的時間。首屏圖片和標題渲染明顯提前了因為不再被一串巨大的腳本卡在最后。這個改造過程有兩點經驗值得說。第一拆包之后的體積收益要配合服務端 gzip 才有最終效果我們同時開了 gzip260KB 的包實際傳輸只有 90KB 左右網絡損耗進一步降低。第二chunk 文件名要加 contenthash否則用戶瀏覽器緩存還是拿舊文件等于白優(yōu)化。4. 常見問題與排錯技巧實錄異步加載用上之后新問題也會跟著來。這里整理幾個出現頻率最高的坑和排查思路基本覆蓋日常開發(fā)的常見雷區(qū)。4.1 異步腳本執(zhí)行順序錯亂用 async 加載兩個互相依賴的腳本運行時報xxx is not defined這種問題在上線大廳調試時非常尷尬。排查思路很直接先看腳本的依賴方向b.js 依賴 a.js 的函數那不能給這兩個腳本都用 async可以改成 defer或者用動態(tài)加載的方式通過 Promise 控制順序。另外注意一個細節(jié)defer 嚴格按文檔順序執(zhí)行但它執(zhí)行的時候文檔已經解析完畢。如果你有一個腳本想“越早執(zhí)行越好”又需要操作 DOM那么腳本位置放body底部配合 defer比放head里更合理。4.2 懶加載導致圖片容器塌陷圖片懶加載的時候如果圖片沒有顯式高度容器高度就是 0等圖片加載完成后容器突然被撐高頁面視覺上會“跳一下”。尤其是列表頁每跳一下用戶都得重新定位閱讀位置體驗非常差。解決辦法是兩個給圖片容器固定寬高或者使用 CSS 的aspect-ratio屬性預設比例。再配合一點 background-color 占位加載過程基本無感。4.3 預加載過度導致首屏變慢新手容易把 preload 當成“萬能加速器”一口氣把首屏所有圖片、字體、 chunk 都塞進 preload。結果是瀏覽器網絡通道被塞滿真正關鍵的腳本和樣式反而排在后面首屏時間不減反增。preload 的合理使用范圍是首屏關鍵資源比如最大那張首屏圖、關鍵字體、首屏必需樣式其余未來資源一律用 prefetch 或者不預加載。4.4 動態(tài) import 的 chunk 請求地址 404項目部署上線后點擊某個按鈕觸發(fā)懶加載Network 面板里看到請求 chunk 文件 404。常見原因是 Webpack 的 publicPath 配置與 CDN 實際目錄不一致。排查路徑先看 Network 面板里請求的完整 URL再對照 CDN 上的實際文件路徑最后檢查構建配置里的 publicPath。另一個隱蔽問題某些 CDN 回源慢導致 chunk 首次訪問超時重試一下能好那就要在加載失敗的重試邏輯上做文章。4.5 性能優(yōu)化過程中容易忽略的隱藏項很多人優(yōu)化完 JS 和圖片發(fā)現首屏還是慢轉頭一看才發(fā)現是字體文件拖后腿。字體加載默認是“阻塞換行渲染”的也就是字體文件沒加載完瀏覽器不會渲染使用了該字體的文本。最通用的解法是font-display: swap讓文本先用替代字體展示字體加載完成后切換。雖然會有極短時間的字體跳變但比起白屏等字體這個代價完全可以接受。還有緩存策略。異步加載的資源文件帶 contenthash 之后可以設置很長的 Cache-Control 過期時間用戶二次訪問時直接走本地緩存不再請求服務器。這一步優(yōu)化對“往返訪問”場景的提速效果比任何加載方案都明顯。5. 寫給正在做性能優(yōu)化的你異步加載這套組合拳打下來我最深的感受是性能優(yōu)化不是“把代碼變少”而是“把代碼出現的時間線重新排列”。用戶感知到的速度取決于“關鍵內容出現在屏幕上的時間”而不是“所有資源都加載完的時間”。認清這一點很多優(yōu)化決策會變得非常清晰——凡是首屏用不到的統(tǒng)統(tǒng)往后排凡是用戶馬上要用的優(yōu)先級拉滿凡是有依賴關系的順序必須可控。最后再分享一個小技巧優(yōu)化完成之后不要只盯著本地的快速網絡數據看。打開 DevTools 的 Network 面板把網絡節(jié)流調到 Slow 3G再跑一遍然后到真機低端機上試一圈。很多優(yōu)化在強網環(huán)境下看起來區(qū)別不大一到弱網環(huán)境就原形畢露。場景越惡劣異步加載做得好的頁面優(yōu)勢越明顯。把弱網下的表現作為驗收標準你優(yōu)化出來的頁面才是真的能打。