“頁(yè)面無(wú)響應(yīng)”這個(gè)事做前端久了基本都會(huì)碰到。最氣人的不是它偶發(fā)一次而是你根本沒(méi)法穩(wěn)定復(fù)現(xiàn)用戶那邊隔三差五來(lái)一句“頁(yè)面又卡死了”你這邊打開DevTools怎么操作都好好的。一旦出現(xiàn)這種情況整個(gè)項(xiàng)目組都會(huì)陷入被動(dòng)運(yùn)營(yíng)催、測(cè)試催、領(lǐng)導(dǎo)也催最后壓力全堆到前端頭上。我前陣子剛處理完一個(gè)線上的類似問(wèn)題從接到反饋到最終修復(fù)前后折騰了差不多一周今天把整個(gè)排查思路、工具用法和優(yōu)化方案整理出來(lái)希望能幫遇到同樣問(wèn)題的人少走點(diǎn)彎路。這篇文章我會(huì)圍繞“Web頁(yè)面頻繁無(wú)響應(yīng)”這個(gè)主題講清楚三個(gè)層面的東西第一怎么區(qū)分不同類型的無(wú)響應(yīng)建立自己的排查框架第二用什么工具、在什么時(shí)機(jī)去采集證據(jù)別靠肉眼猜第三定位到根因之后有哪些行之有效的優(yōu)化手段。內(nèi)容偏實(shí)戰(zhàn)適合有一定前端基礎(chǔ)、但遇到性能問(wèn)題還不太知道怎么下手的同學(xué)也適合準(zhǔn)備前端面試時(shí)想拿“性能優(yōu)化”這個(gè)點(diǎn)講出深度的人。1. 先搞清楚“頁(yè)面無(wú)響應(yīng)”到底屬于哪一類很多人一聽到“頁(yè)面無(wú)響應(yīng)”第一反應(yīng)就是“主線程被阻塞了”然后趕緊打開Performance面板去錄一段結(jié)果錄了半天什么也沒(méi)抓到。這是因?yàn)椤盁o(wú)響應(yīng)”其實(shí)是一個(gè)很籠統(tǒng)的說(shuō)法它可能對(duì)應(yīng)好幾種完全不同的底層現(xiàn)象而不同現(xiàn)象對(duì)應(yīng)的排查路徑是完全不一樣的。1.1 把現(xiàn)象拆開看白屏、卡頓、假死和崩潰我習(xí)慣把“無(wú)響應(yīng)”拆成四類來(lái)看第一類是白屏。頁(yè)面打開后一片空白或者某個(gè)路由跳轉(zhuǎn)后內(nèi)容區(qū)域空白用戶點(diǎn)哪里都沒(méi)反應(yīng)。這種情況通常是JS執(zhí)行報(bào)錯(cuò)、資源加載失敗、或者渲染鏈路斷裂導(dǎo)致的。第二類是卡頓。用戶能操作但點(diǎn)擊之后要等很久才有反饋滾動(dòng)頁(yè)面像幻燈片一樣一頓一頓的。這種情況一般是主線程上連續(xù)執(zhí)行了太多同步任務(wù)瀏覽器來(lái)不及渲染每一幀。第三類是假死。頁(yè)面還停留在上一個(gè)畫面但鼠標(biāo)點(diǎn)擊、鍵盤輸入全部失效標(biāo)簽頁(yè)標(biāo)題變成“無(wú)響應(yīng)”過(guò)幾秒又恢復(fù)或者一直恢復(fù)不了。這種情況是主線程被一個(gè)超長(zhǎng)任務(wù)完全占住了瀏覽器的事件循環(huán)轉(zhuǎn)不過(guò)來(lái)連渲染都沒(méi)機(jī)會(huì)執(zhí)行。第四類是崩潰。標(biāo)簽頁(yè)直接變成“頁(yè)面崩潰”提示刷新都沒(méi)用。這種情況往往是內(nèi)存占用過(guò)高、渲染進(jìn)程直接被殺掉。從排查難度來(lái)講卡頓最容易錄到證據(jù)白屏其次假死最坑的是那種“偶發(fā)幾秒又恢復(fù)”的情況崩潰則需要重點(diǎn)看內(nèi)存曲線。1.2 建立自己的排查框架先看現(xiàn)象再定方向我在處理這類問(wèn)題的時(shí)候會(huì)先跟反饋人確認(rèn)幾個(gè)關(guān)鍵信息發(fā)生頻率次/天、發(fā)生場(chǎng)景首屏打開還是操作中、持續(xù)時(shí)長(zhǎng)秒級(jí)還是永久、瀏覽器和系統(tǒng)版本、是否必現(xiàn)。這些信息看起來(lái)簡(jiǎn)單但如果第一個(gè)反饋人說(shuō)“經(jīng)常無(wú)響應(yīng)”就埋頭開干很容易被偶發(fā)性帶到溝里去。以前我用過(guò)一個(gè)笨辦法讓用戶下次卡住的時(shí)候按一下刷新鍵問(wèn)“刷新后能不能恢復(fù)”再問(wèn)“卡住之前最后做的一個(gè)操作是什么”。這兩個(gè)問(wèn)題的答案往往能直接縮小排查范圍。如果是刷新后恢復(fù)正?；究梢耘懦布蜑g覽器層面的問(wèn)題重點(diǎn)考慮代碼里的資源占用或請(qǐng)求掛起如果是某個(gè)特定操作后必現(xiàn)那就直接審查那個(gè)操作的實(shí)現(xiàn)代碼。判斷完現(xiàn)象和觸發(fā)場(chǎng)景之后再去選工具就會(huì)很有針對(duì)性。比如卡頓類問(wèn)題重點(diǎn)看Long Tasks和FPS假死類問(wèn)題重點(diǎn)看主線程時(shí)間軸上的長(zhǎng)任務(wù)崩潰類問(wèn)題重點(diǎn)看Memory面板的內(nèi)存曲線和堆快照對(duì)比。2. 定位工具鏈別靠肉眼猜讓數(shù)據(jù)說(shuō)話定位“頁(yè)面無(wú)響應(yīng)”最忌諱的就是憑空猜。這里先分享一個(gè)真實(shí)例子我之前有個(gè)同事排查頁(yè)面卡死他懷疑是某個(gè)第三方庫(kù)的Bug花了三天時(shí)間翻那個(gè)庫(kù)的源碼最后發(fā)現(xiàn)根因根本不是這個(gè)庫(kù)而是自己業(yè)務(wù)代碼里一個(gè)無(wú)意間寫出的無(wú)限循環(huán)。所以工具和數(shù)據(jù)永遠(yuǎn)比感覺靠譜。2.1 Performance面板的正確打開方式用Performance面板錄制的核心操作其實(shí)不復(fù)雜打開DevTools切到Performance面板點(diǎn)擊錄制按鈕然后讓頁(yè)面執(zhí)行出那個(gè)“無(wú)響應(yīng)”的操作再點(diǎn)停止。錄制完成后主線程的時(shí)間軸圖會(huì)清晰地展示每一幀的工作狀態(tài)。我自己的習(xí)慣是這樣的錄制前清一下瀏覽器緩存控制變量如果頁(yè)面是首次打開就出問(wèn)題就從刷新前開始錄制如果是操作中出問(wèn)題就先把頁(yè)面恢復(fù)到出問(wèn)題前的狀態(tài)再開始錄。錄制時(shí)間控制在10到20秒太短抓不到長(zhǎng)任務(wù)太長(zhǎng)數(shù)據(jù)冗余反而難分析。停止錄制后我優(yōu)先看三個(gè)東西第一個(gè)是紅色的“長(zhǎng)任務(wù)”標(biāo)記。Chrome會(huì)直接把超過(guò)50毫秒的任務(wù)標(biāo)紅這些就是阻塞用戶交互和渲染的元兇。點(diǎn)開標(biāo)紅的任務(wù)塊能直接看到這個(gè)任務(wù)在哪個(gè)腳本、哪個(gè)函數(shù)上消耗了最多時(shí)間。第二個(gè)是FPS曲線。如果錄制期間FPS頻繁掉到20以下說(shuō)明渲染鏈路有問(wèn)題。FPS低不一定是JS的問(wèn)題也可能是樣式計(jì)算、圖層合并導(dǎo)致的。第三個(gè)是“Summary”板塊里各類型時(shí)間占比。如果Scripting占比超過(guò)60%那JS計(jì)算就是瓶頸如果Rendering和Painting占比高就要去檢查CSS和圖層策略。為了抓偶發(fā)的假死問(wèn)題我還會(huì)開Performance Monitor面板它是實(shí)時(shí)監(jiān)控CPU占用、JS堆大小和DOM節(jié)點(diǎn)數(shù)量的。設(shè)置成常駐窗口等頁(yè)面卡住的那一瞬間趕緊切過(guò)去截圖能看到卡死前CPU是不是100%、堆內(nèi)存是不是一直在漲。2.2 用Performance API做自動(dòng)監(jiān)控手動(dòng)錄制只能解決“能復(fù)現(xiàn)”的問(wèn)題線上偶發(fā)問(wèn)題靠人工盯著根本不現(xiàn)實(shí)所以我把Long Tasks的監(jiān)控代碼直接埋到了項(xiàng)目里。核心是利用瀏覽器的PerformanceObserver接口去監(jiān)聽長(zhǎng)任務(wù)事件代碼很簡(jiǎn)單const observer new PerformanceObserver((list) { for (const entry of list.getEntries()) { if (entry.duration 100) { // 上報(bào)到日志平臺(tái)記錄時(shí)長(zhǎng)和來(lái)源腳本 report({ type: long-task, duration: entry.duration, startTime: entry.startTime, name: entry.name || , attribution: entry.attribution || [] }); } } }); observer.observe({ entryTypes: [longtask] });這里有一個(gè)細(xì)節(jié)Long Task API返回的attribution里包含TASKS.SCRIPT_URL這樣的屬性能直接告訴你是哪個(gè)腳本文件執(zhí)行超過(guò)了閾值這對(duì)定位第三方腳本導(dǎo)致的主線程阻塞非常有幫助。我在實(shí)際項(xiàng)目里就把好幾個(gè)廣告SDK的腳本錄出來(lái)了實(shí)錘是他們的問(wèn)題。除了Long Task我還會(huì)用performance.getEntriesByType(navigation)去采集頁(yè)面加載階段的各階段耗時(shí)把DNS查詢、TCP連接、請(qǐng)求響應(yīng)、DOM解析、腳本執(zhí)行這幾個(gè)關(guān)鍵耗時(shí)數(shù)據(jù)上報(bào)到監(jiān)控平臺(tái)。這樣每次頁(yè)面打開耗時(shí)多少、哪一段耗時(shí)異常都有數(shù)據(jù)支撐不用等用戶反饋。另外我強(qiáng)烈推薦所有前端團(tuán)隊(duì)都去用一下瀏覽器自帶的“任務(wù)管理器”。它不是DevTools里的那個(gè)Memory面板而是瀏覽器右上角菜單里的“更多工具-任務(wù)管理器”。它能實(shí)時(shí)顯示每個(gè)標(biāo)簽頁(yè)的CPU占用率和內(nèi)存占用頁(yè)面卡住的時(shí)候這個(gè)標(biāo)簽頁(yè)的CPU如果飆到100%以上那你基本可以確定問(wèn)題出在主線程計(jì)算密集或者有死循環(huán)如果CPU不高但內(nèi)存一直漲那方向就要轉(zhuǎn)向內(nèi)存泄漏。這個(gè)工具在真機(jī)模擬和線上問(wèn)題排查時(shí)效率特別高很多新手都不知道它的存在。3. 深挖根因常見導(dǎo)致頁(yè)面無(wú)響應(yīng)的五類元兇排查工具掌握之后下一步就是識(shí)別根因。我接手過(guò)不少“無(wú)響應(yīng)”類問(wèn)題總結(jié)下來(lái)絕大多數(shù)都跑不出下面五類原因?qū)μ?hào)入座就能省下一大半時(shí)間。3.1 主線程被長(zhǎng)任務(wù)霸占同步計(jì)算和大數(shù)據(jù)處理這是最常見的一類。頁(yè)面主線程本來(lái)就要承擔(dān)事件處理、樣式計(jì)算、渲染、布局、垃圾回收這些活一旦一個(gè)同步任務(wù)占了超過(guò)某個(gè)時(shí)間片段瀏覽器的整體響應(yīng)就會(huì)變得不跟手。如果這個(gè)任務(wù)超過(guò)一兩秒頁(yè)面就直接進(jìn)入“無(wú)響應(yīng)”狀態(tài)。我處理過(guò)一個(gè)數(shù)據(jù)可視化的項(xiàng)目每次篩選數(shù)據(jù)都會(huì)卡死。最后定位到問(wèn)題出在一段對(duì)兩三萬(wàn)條數(shù)據(jù)進(jìn)行多層filter和sort操作上。每次篩選都同步處理還要同時(shí)生成若干個(gè)圖表配置對(duì)象主線程直接被打滿。這種場(chǎng)景的優(yōu)化思路我后面會(huì)詳細(xì)講核心就是兩條把大任務(wù)拆成小任務(wù)或者把重計(jì)算挪到Worker線程。判斷一段代碼是不是長(zhǎng)任務(wù)可以手動(dòng)看執(zhí)行時(shí)間但更推薦用Performance面板錄制直接看標(biāo)紅的區(qū)塊和對(duì)應(yīng)的函數(shù)名。如果函數(shù)名是被壓縮過(guò)的比如上線后的代碼記得在Sources面板里開啟Source Map才能定位到源碼。3.2 渲染層頻繁重排重繪布局抖動(dòng)和樣式風(fēng)暴頁(yè)面“無(wú)響應(yīng)”和“卡頓”經(jīng)常是疊加出現(xiàn)的其中渲染層的頻繁重排重繪是很重要的一環(huán)。有些操作本身不算重但如果在一個(gè)高頻觸發(fā)的流程里反復(fù)觸發(fā)強(qiáng)制同步布局整個(gè)頁(yè)面就會(huì)變得非?？?。最典型的反模式是在循環(huán)里不停地讀offsetWidth、clientTop這樣的布局屬性然后立刻修改樣式。瀏覽器為了返回正確的布局值只能中止當(dāng)前的樣式計(jì)算和布局流程強(qiáng)制做一次同步重排這就是強(qiáng)制同步布局也叫布局抖動(dòng)。一兩個(gè)還好循環(huán)里調(diào)幾千次渲染線程直接崩潰頁(yè)面表現(xiàn)為滾動(dòng)卡成PPT、點(diǎn)擊延遲幾秒。3.3 內(nèi)存泄漏堆內(nèi)存越漲越高最終引發(fā)渲染進(jìn)程崩潰內(nèi)存泄漏導(dǎo)致的“無(wú)響應(yīng)”有一個(gè)顯著特征頁(yè)面剛打開的時(shí)候是好的用著用著越來(lái)越卡最后點(diǎn)什么都沒(méi)反應(yīng)嚴(yán)重時(shí)標(biāo)簽頁(yè)直接崩潰。這種問(wèn)題你錄Performance面板還不夠得結(jié)合Memory面板的堆快照對(duì)比來(lái)排查。常見的泄漏源頭有幾個(gè)沒(méi)有清理的setInterval或setTimeout定時(shí)器、沒(méi)有被解綁的DOM事件監(jiān)聽器、全局變量引用、閉包意外持有的大對(duì)象、以及Vue或React里沒(méi)有正確銷毀的組件實(shí)例和watcher。我見過(guò)一個(gè)真實(shí)案例項(xiàng)目里用addEventListener注冊(cè)了滾動(dòng)監(jiān)聽組件銷毀時(shí)忘了removeEventListener導(dǎo)致每次進(jìn)出頁(yè)面都多一份監(jiān)聽器DOM節(jié)點(diǎn)和監(jiān)聽器越來(lái)越多最終頁(yè)面在低端機(jī)上徹底卡死。排查內(nèi)存泄漏我的建議是在Memory面板里連續(xù)采集三次堆快照加載完成時(shí)取一次、操作一段時(shí)間后取一次、觸發(fā)垃圾回收后再取一次。對(duì)比這三份快照如果一些對(duì)象的實(shí)例數(shù)只增不減那就是泄漏點(diǎn)。另外Chrome的Heap Snapshot里還支持按“Detached”來(lái)篩選被分離的DOM節(jié)點(diǎn)這些節(jié)點(diǎn)從文檔中摘除了但依然被JS引用著是最典型的泄漏對(duì)象。3.4 網(wǎng)絡(luò)層掛起有響應(yīng)框但請(qǐng)求永遠(yuǎn)在pending還有一種“無(wú)響應(yīng)”比較迷惑頁(yè)面本身沒(méi)死按鈕也能點(diǎn)但所有請(qǐng)求都pending界面一直處于加載狀態(tài)。用戶感知就是“點(diǎn)哪兒都沒(méi)反應(yīng)”。這類問(wèn)題最常見的原因是后端接口過(guò)慢或者某個(gè)接口被并發(fā)請(qǐng)求拖垮前端沒(méi)有做超時(shí)控制。比如頁(yè)面上同時(shí)掛了十幾個(gè)接口其中有一個(gè)耗時(shí)30秒而這個(gè)接口阻塞了后續(xù)的關(guān)鍵內(nèi)容渲染用戶看到的就是一大片空白轉(zhuǎn)圈圈轉(zhuǎn)到懷疑人生。前端要做的優(yōu)化一方面是把必要的請(qǐng)求和可延后的請(qǐng)求分開核心鏈路先加載非核心模塊異步加載另一方面要給所有請(qǐng)求設(shè)置合理的超時(shí)時(shí)間配合統(tǒng)一的錯(cuò)誤處理和重試策略。還有一個(gè)容易被忽視的坑是Service Worker如果你項(xiàng)目里注冊(cè)了Service Worker一旦它的緩存策略有問(wèn)題會(huì)讓某些請(qǐng)求永遠(yuǎn)處于pending狀態(tài)表現(xiàn)上跟“頁(yè)面無(wú)響應(yīng)”一樣。我查過(guò)一個(gè)項(xiàng)目就是因?yàn)镾ervice Worker的回調(diào)里Promise一直沒(méi)resolve導(dǎo)致頁(yè)面請(qǐng)求全部掛起。3.5 無(wú)限循環(huán)和異常遞歸代碼級(jí)Bug瞬間壓垮頁(yè)面最后這一類屬于硬核Bug型不是數(shù)據(jù)大也不是渲染復(fù)雜而是代碼寫錯(cuò)了。最常見的是while循環(huán)條件寫反、遞歸沒(méi)有出口、或者一些不自知的高頻調(diào)用。比如我在項(xiàng)目里遇到過(guò)一個(gè)問(wèn)題某個(gè)watch里監(jiān)聽了數(shù)據(jù)變化然后又修改了同一份數(shù)據(jù)觸發(fā)下一次watch形成了一個(gè)無(wú)限循環(huán)Vue還給了警告“You may have an infinite update loop in a component render function”但很多人忽略了。這種循環(huán)往往在幾秒內(nèi)就能讓CPU沖到極限頁(yè)面直接假死。排查這種問(wèn)題最快的辦法是看Performance面板里長(zhǎng)任務(wù)的調(diào)用棧如果在某個(gè)函數(shù)里反復(fù)循環(huán)跳不出來(lái)調(diào)用棧上看得很清楚。也可以用Node.js的--inspect調(diào)試遠(yuǎn)程定位但前端場(chǎng)景還是DevTools性能錄制更直接。4. 優(yōu)化方案落地從一個(gè)長(zhǎng)任務(wù)到一個(gè)順滑頁(yè)面通過(guò)前面幾步找到根因之后就到了真正動(dòng)手優(yōu)化的階段。這一章我會(huì)把高頻用到的優(yōu)化方案拆開講每一類都可以直接“抄作業(yè)”式落地。4.1 拆解大任務(wù)時(shí)間切片和時(shí)間窗口“時(shí)間切片”的核心思想是把一個(gè)超過(guò)50毫秒的同步長(zhǎng)任務(wù)拆成多個(gè)小于50毫秒的短任務(wù)讓瀏覽器有機(jī)會(huì)在每個(gè)任務(wù)間隙去響應(yīng)事件和渲染頁(yè)面。這樣用戶的點(diǎn)擊不會(huì)等待太久頁(yè)面看起來(lái)就“有響應(yīng)”。最簡(jiǎn)單的一種拆分方式是用requestAnimationFrame分檔處理。比如要循環(huán)處理兩萬(wàn)條數(shù)據(jù)可以每幀只處理一小部分代碼大致是這樣的function processLargeArray(items, processFn, batchSize 500) { let index 0; function nextBatch() { const end Math.min(index batchSize, items.length); for (; index end; index) { processFn(items[index]); } if (index items.length) { requestAnimationFrame(nextBatch); } } requestAnimationFrame(nextBatch); }這里用frames作為時(shí)間窗口每執(zhí)行完一批就讓出主線程讓頁(yè)面能處理用戶事件和渲染。如果任務(wù)不那么緊急可以用requestIdleCallback來(lái)執(zhí)行專門利用瀏覽器的空閑時(shí)間片避免阻塞關(guān)鍵交互。requestIdleCallback還帶一個(gè)超時(shí)參數(shù)可以控制它最多延遲多久“必要時(shí)可以等但不能無(wú)限等”。4.2 計(jì)算密集型任務(wù)交給Web Worker如果數(shù)據(jù)處理邏輯非常重比如解析大JSON、復(fù)雜計(jì)算、圖片處理、數(shù)據(jù)轉(zhuǎn)換前端的主線程真的不合適。這種場(chǎng)景最好把計(jì)算任務(wù)放到Web Worker里Worker運(yùn)行在獨(dú)立的線程不會(huì)阻塞UI渲染。一個(gè)完整的Worker用法是這樣的主線程里通過(guò)new Worker(...)建一個(gè)子線程用postMessage傳參用onmessage接收結(jié)果。Worker內(nèi)部跑完計(jì)算后再把結(jié)果postMessage回主線程。核心代碼如下// main.js const worker new Worker(/workers/dataProcessor.js); worker.onmessage (e) { const result e.data; // 拿到計(jì)算結(jié)果再去更新渲染 renderList(result); }; worker.onerror (error) { console.error(Worker error:, error); }; // 把原始數(shù)據(jù)發(fā)給Worker worker.postMessage({ rawData, config }); // dataProcessor.js self.onmessage (e) { const { rawData, config } e.data; const result heavyProcess(rawData, config); self.postMessage(result); };這里要提醒兩件事第一Worker里拿不到DOM和window只能做純計(jì)算第二postMessage傳遞數(shù)據(jù)時(shí)會(huì)有結(jié)構(gòu)化克隆的開銷如果數(shù)據(jù)特別大幾十MB級(jí)別能傳引用而不是全部拷貝就傳引用比如用Transferable對(duì)象。另外需要長(zhǎng)駐的Worker記得在某個(gè)時(shí)機(jī)terminate()不然內(nèi)存管理也是個(gè)問(wèn)題。4.3 大數(shù)據(jù)列表虛擬滾動(dòng)是剛需列表渲染是前端性能問(wèn)題的高發(fā)區(qū)。如果一個(gè)頁(yè)面要展示上千條、上萬(wàn)條數(shù)據(jù)最簡(jiǎn)單的v-for或者map生成DOM都會(huì)導(dǎo)致DOM節(jié)點(diǎn)爆炸首屏渲染就要很久滾動(dòng)起來(lái)更新也很吃力。用戶操作起來(lái)就會(huì)明顯感覺“頁(yè)面無(wú)響應(yīng)”。虛擬滾動(dòng)的核心思路是不管總數(shù)據(jù)量有多大只渲染可視區(qū)域內(nèi)的那幾條DOM。監(jiān)聽滾動(dòng)事件動(dòng)態(tài)計(jì)算當(dāng)前應(yīng)該顯示的數(shù)據(jù)片段用一個(gè)上下偏移把真實(shí)滾動(dòng)高度模擬出來(lái)。市面上現(xiàn)成的庫(kù)有vue-virtual-scroller、react-window等但我更推薦理解原理后自己寫一個(gè)輕量的因?yàn)樵趶?fù)雜業(yè)務(wù)里往往需要定制。核心思路很簡(jiǎn)單容器固定高度內(nèi)容區(qū)的高度等于總條目數(shù)乘以每條目高度用來(lái)?yè)纬鰸L動(dòng)條根據(jù)容器的scrollTop計(jì)算出可視區(qū)域起始索引startIndex Math.floor(scrollTop / itemHeight)再根據(jù)容器高度算出endIndex真正渲染的只有startIndex到endIndex之間的那部分?jǐn)?shù)據(jù)再絕對(duì)定位到正確位置。幾百行代碼就能實(shí)現(xiàn)一個(gè)夠用的版本性能提升是數(shù)量級(jí)的從幾萬(wàn)個(gè)DOM節(jié)點(diǎn)直接降到幾十個(gè)。滾動(dòng)的時(shí)候要注意配合防抖或requestAnimationFrame降低計(jì)算頻率不然監(jiān)聽器本身又是一個(gè)新的性能負(fù)擔(dān)。4.4 防抖和節(jié)流高頻事件的統(tǒng)一解法scroll、resize、mousemove、input輸入這類高頻事件如果handler里做的事情比較重都會(huì)給主線程增加大量壓力。這里防抖和節(jié)流的選用有一條經(jīng)驗(yàn)法則如果目標(biāo)事件是“用戶停止操作后再做一次”用防抖如果目標(biāo)操作是“即使高頻觸發(fā)也要按固定頻率執(zhí)行”用節(jié)流。一個(gè)簡(jiǎn)單的節(jié)流函數(shù)示例function throttle(fn, limit 100) { let inThrottle false; return function(...args) { if (!inThrottle) { fn.apply(this, args); inThrottle true; setTimeout(() { inThrottle false; }, limit); } }; } window.addEventListener(scroll, throttle(onScroll, 100));防抖函數(shù)核心是clearTimeout然后再setTimeout也是十幾行就能實(shí)現(xiàn)。不過(guò)我想強(qiáng)調(diào)的是不要為了用防抖而防抖而是要先量化一下handler到底消耗了多少資源。如果只是一個(gè)簡(jiǎn)單的樣式切換防抖反而會(huì)降低交互響應(yīng)速度得不償失。4.5 渲染優(yōu)化避免強(qiáng)制同步布局和長(zhǎng)鏈?zhǔn)綐邮礁乱腠?yè)面不卡渲染層的優(yōu)化同樣重要。首先要規(guī)避在布局信息讀取和樣式修改之間反復(fù)切換的問(wèn)題。正確的做法是先批量讀取布局信息再批量修改樣式把讀寫分離。用一個(gè)例子說(shuō)明// 不良寫法循環(huán)里讀一次改一次每次都觸發(fā)同步布局 for (let i 0; i items.length; i) { const width item.clientWidth; // 讀 item.style.width width 10 px; // 寫 } // 優(yōu)化寫法先統(tǒng)一讀再統(tǒng)一寫 const widths items.map(item item.clientWidth); items.forEach((item, i) { item.style.width widths[i] 10 px; });另外引起大面積重排的樣式屬性盡量避開。比如修改width、height、left、top這些會(huì)觸發(fā)布局的屬性如果動(dòng)畫只需要視覺變化盡量用transform和opacity代替它們能走合成線程不觸發(fā)重排和重繪。如果頁(yè)面里有復(fù)雜的固定背景或遮罩層可以設(shè)置will-change屬性讓瀏覽器提前優(yōu)化但不要濫用否則內(nèi)存占用也會(huì)增加反而弄巧成拙。4.6 緩存與資源加載讓頁(yè)面最快進(jìn)入可交互狀態(tài)從資源加載角度說(shuō)頁(yè)面無(wú)響應(yīng)也經(jīng)常和首屏加載時(shí)間過(guò)長(zhǎng)有關(guān)。用戶在頁(yè)面白屏的那幾秒里反復(fù)點(diǎn)擊頁(yè)面還沒(méi)有綁定事件用戶的感覺就是“沒(méi)反應(yīng)”。針對(duì)資源加載我會(huì)從三個(gè)層面去優(yōu)化第一代碼分拆把首屏不需要的代碼放到動(dòng)態(tài)import里減少初始JS體積第二利用瀏覽器緩存策略對(duì)不常變的靜態(tài)資源和接口CDN做合理緩存第三關(guān)鍵渲染鏈路上的CSS同步加載非關(guān)鍵的CSS、JS全部異步或者延遲加載。這部分要特別注意一個(gè)反向優(yōu)化的坑緩存設(shè)置太久用戶更新不到新版頁(yè)面會(huì)反饋“頁(yè)面做這么爛點(diǎn)了都沒(méi)反應(yīng)”。這種情況不是性能問(wèn)題而是緩存策略和前端資源版本管理脫節(jié)了。我在nginx部署多個(gè)前端項(xiàng)目時(shí)就專門為不同項(xiàng)目設(shè)置了不同的資源路徑前綴配合文件指紋文件名加hash更新保證用戶既能享受緩存提速又能及時(shí)拿到新版本。這里可以看幾個(gè)核心的nginx配置思路location /project-a/ { alias /data/www/project-a/; try_files $uri $uri/ /project-a/index.html; location ~* \.(js|css|png|jpg|svg|woff2?)$ { expires 30d; # 帶hash的靜態(tài)資源可以放心長(zhǎng)緩存 add_header Cache-Control public, immutable; } } location /project-b/ { alias /data/www/project-b/; try_files $uri $uri/ /project-b/index.html; location ~* \.html$ { add_header Cache-Control no-cache; # html入口不做長(zhǎng)緩存 } }不明白Cache-Control的人很容易把“緩存”和“無(wú)響應(yīng)”搞混。拿到一個(gè)“頁(yè)面無(wú)響應(yīng)”的反饋先確認(rèn)一下是渲染問(wèn)題、數(shù)據(jù)加載問(wèn)題還是緩存策略問(wèn)題這一步很關(guān)鍵。5. 一次完整實(shí)戰(zhàn)線上偶發(fā)卡死的定位與修復(fù)記錄理論講了不少我再用一個(gè)實(shí)際處理過(guò)的案例把從接需求到一次修復(fù)的全流程串一遍。這個(gè)案例是一個(gè)后臺(tái)管理系統(tǒng)技術(shù)棧是Vue Element Plus用戶反饋在某個(gè)低配Windows電腦上打開某條列表數(shù)據(jù)詳情頁(yè)之后頁(yè)面頻繁進(jìn)入“未響應(yīng)”狀態(tài)每次持續(xù)幾秒到十幾秒不定運(yùn)氣好能自己緩過(guò)來(lái)運(yùn)氣差直接白屏。5.1 第一輪采集信息確認(rèn)觸發(fā)條件我接到反饋后沒(méi)有直接動(dòng)代碼先遠(yuǎn)程到用戶的電腦上看了一下現(xiàn)場(chǎng)。排查后確認(rèn)了幾個(gè)關(guān)鍵信息只在Windows上的Chrome低版本復(fù)現(xiàn)打開詳情頁(yè)之后點(diǎn)擊左側(cè)菜單切換路由時(shí)必卡頁(yè)面停留越久卡死概率越高刷新后能恢復(fù)正常但再點(diǎn)進(jìn)詳情頁(yè)又會(huì)復(fù)發(fā)。這個(gè)信息里有幾個(gè)關(guān)鍵詞給了我方向“切換路由時(shí)必卡”意味著路由切換這個(gè)動(dòng)作觸發(fā)了某個(gè)重操作“停留越久概率越高”意味著可能有狀態(tài)在累積或者內(nèi)存占用越來(lái)越高“刷新能恢復(fù)”說(shuō)明不是瀏覽器層面的徹底崩潰而是運(yùn)行時(shí)資源耗盡。當(dāng)時(shí)我順手打開了瀏覽器自帶的任務(wù)管理器頁(yè)面卡住的時(shí)候看到Chrome的CPU占用率在120%到300%之間瘋狂波動(dòng)。到這里我可以基本鎖定問(wèn)題是主線程任務(wù)過(guò)重。5.2 第二輪性能錄制找到具體長(zhǎng)任務(wù)接著我在本機(jī)開始復(fù)現(xiàn)。先在DevTools里打開Performance面板開始錄制然后模擬用戶一路進(jìn)入詳情頁(yè)再切菜單10秒后停止錄制。時(shí)間軸上一片紅色長(zhǎng)任務(wù)最長(zhǎng)的幾個(gè)任務(wù)耗時(shí)在1200毫秒到3000毫秒不等。點(diǎn)開最長(zhǎng)的那個(gè)任務(wù)調(diào)用棧指向了一個(gè)組件內(nèi)的computed屬性函數(shù)名字被壓縮過(guò)但順著Source Map就能定位到源碼。這個(gè)computed做的事情是把詳情頁(yè)里的一個(gè)幾千條元素的數(shù)組按若干維度做篩選、排序、再組裝成樹形結(jié)構(gòu)。按設(shè)計(jì)它只在數(shù)據(jù)變化時(shí)重算一次但實(shí)際上詳情頁(yè)里還有一個(gè)定時(shí)器每5秒去輪詢一次后端接口刷新數(shù)據(jù)而輪詢回來(lái)的新對(duì)象會(huì)被直接賦值給響應(yīng)式數(shù)據(jù)于是computed頻繁觸發(fā)每次都要重新算一遍幾千條數(shù)據(jù)的樹形結(jié)構(gòu)主線程被徹底拖垮。定位到問(wèn)題之后我給這次問(wèn)題定了性業(yè)務(wù)定時(shí)輪詢觸發(fā)了全量重算復(fù)雜度是O(N^3)級(jí)別的多循環(huán)嵌套加上數(shù)據(jù)量本身不小導(dǎo)致單次計(jì)算超過(guò)1秒。路由切換時(shí)又把舊的組件銷毀、新組件渲染疊加在一起長(zhǎng)任務(wù)就更加明顯。5.3 第三輪分步優(yōu)化最終穩(wěn)定平滑修復(fù)分了三步走。第一步把輪詢數(shù)據(jù)的更新方式從“整體覆蓋”改成“按需合并”。后端返回的新列表先跟當(dāng)前列表做差異對(duì)比只有真正變化的字段和條目才觸發(fā)響應(yīng)式更新。這里用一個(gè)Map以ID為鍵做映射判斷前后數(shù)據(jù)是否相同相同就跳過(guò)賦值。這個(gè)改動(dòng)直接讓computed的觸發(fā)頻率降低了95%以上。第二步把樹形結(jié)構(gòu)的組裝從computed里拿出來(lái)。因?yàn)檫@個(gè)計(jì)算確實(shí)是頁(yè)面展示依賴的不能省但計(jì)算成本太高所以我把它改成了懶計(jì)算加緩存只有用戶真正展開某棵子樹的時(shí)候才去計(jì)算那一層的結(jié)構(gòu)并且用緩存存儲(chǔ)已展開的節(jié)點(diǎn)避免重復(fù)計(jì)算。這一步把單次計(jì)算時(shí)間從1000毫秒降到了180毫秒左右。第三步給渲染層加上虛擬滾動(dòng)。詳情頁(yè)里展示樹形數(shù)據(jù)的區(qū)域一次最多只渲染可視區(qū)域內(nèi)的節(jié)點(diǎn)配合展開狀態(tài)做局部更新。這一步看著是渲染優(yōu)化其實(shí)是給整體交互“松綁”即使數(shù)據(jù)再多一些也不至于重新回到卡頓狀態(tài)。優(yōu)化完之后我又回到用戶那臺(tái)低配電腦上實(shí)測(cè)。優(yōu)化前打開詳情頁(yè)然后點(diǎn)菜單平均等待3到5秒才有反應(yīng)優(yōu)化后點(diǎn)擊菜單到新的頁(yè)面渲染出來(lái)基本穩(wěn)定在200到300毫秒CPU占用率從峰值300%降到60%以下。后來(lái)再也沒(méi)收到過(guò)這個(gè)頁(yè)面的“無(wú)響應(yīng)”反饋。整個(gè)過(guò)程走下來(lái)我的體感是定位這類問(wèn)題核心不是會(huì)多少API而是能否一步一步縮小范圍用數(shù)據(jù)做決策。Performance錄制定位長(zhǎng)任務(wù)、任務(wù)管理器看CPU、Memory對(duì)比堆快照這三板斧足夠應(yīng)付90%的頁(yè)面無(wú)響應(yīng)問(wèn)題。現(xiàn)在哪怕接到的反饋只有一句“頁(yè)面卡了”我也會(huì)先把這三個(gè)工具順手開起來(lái)等下次再犯的時(shí)候就能抓到現(xiàn)場(chǎng)后面的事情就好辦多了。再分享一個(gè)小技巧解決完一個(gè)問(wèn)題之后不要急著關(guān)掉DevTools。順手把這次的復(fù)現(xiàn)路徑、長(zhǎng)任務(wù)截圖、優(yōu)化前后數(shù)據(jù)對(duì)比整理到團(tuán)隊(duì)的wiki或文檔里。以后再遇到類似問(wèn)題先搜文檔很多坑前人已經(jīng)替你踩過(guò)了。另外如果有余力可以把5.2里那個(gè)PerformanceObserver的長(zhǎng)任務(wù)監(jiān)控埋到生產(chǎn)環(huán)境里設(shè)置合理的上報(bào)閾值這樣線上問(wèn)題就不再完全依賴用戶反饋了你甚至能在用戶感知之前就發(fā)現(xiàn)隱患。