頁面卡頓的技術根源在主線程：掘金長文梳理每幀10毫秒預算與2026年四類解法

2026年9月5日，技術社羣掘金出現一篇標題為「你的頁面為什麼總是卡成PPT？2026年，90%的前端都忽略了主線程」的長文，作者署名「濤濤ing」，全文約七分鐘閱讀長度，聚焦瀏覽器主線程的效能瓶頸。本臺以回顧角度，整理文中可核實的數據、成因分析與解法輪廓，並對照公開的瀏覽器規範進展。

每幀16.7毫秒，留給JavaScript的只有約10毫秒

文章的核心論證建立在一組時間預算上。在60Hz更新率的螢幕上，瀏覽器每一幀的總時間約為16.7毫秒；扣除瀏覽器自身的開銷後，留給JavaScript執行的時間大約只剩10毫秒。這段時間內，頁面必須完成使用者輸入的回應、DOM更新、網路請求回呼與動畫影格等工作。

文中引用TLDR Dev的一篇文章指出，任何執行超過50毫秒的任務都會被瀏覽器標記為「長任務」（Long Task），直接阻塞使用者輸入，並拉高INP（Interaction to Next Paint）指標。INP在2026年已是Core Web Vitals中最核心的互動效能指標。換言之，頁面「功能都正常，但用起來就是卡」的常見體感，來自功能與體驗同時競爭主線程的執行時間。

主線程承擔的工作包括執行JavaScript、處理點擊滾動與鍵盤輸入、樣式計算、布局與繪製。作者形容它是瀏覽器裡最忙的一條單行道。在Chrome DevTools的Performance面板中，若看到滿屏黃色長條，即為主線程被長時間佔用的視覺化訊號。

與這篇技術討論同期的社羣脈絡中，前端就業與技術方向本身也是爭論議題，牛客網前端方向討論帖所反映的行業焦慮，與效能優化被視為工程師差異化能力的說法，構成對照背景。

文中列舉的三類阻塞來源

文章將主線程阻塞歸納為三類。第一類是巨大的初始化JavaScript。當代React或Vue應用的main.js動輒數百KB甚至超過1MB，瀏覽器必須完成下載、解析、編譯與執行的完整流程，使用者才能看到第一個有意義的畫面。作者引述一個優化案例，稱拆解初始化長任務並採用任務分片執行後，主線程的持續佔用時長明顯下降。

第二類是高頻觸發的渲染重排。修改width、height、padding、margin、border、font-size等改變幾何屬性的樣式，會觸發整棵布局樹的重新計算；若在一次滾動事件中修改十個元素的寬度，瀏覽器就要重新計算十次布局。文中指出，真正成本低的動畫屬性只有transform與opacity兩項，兩者由GPU處理，不觸發重排。

第三類是在主線程上執行CPU密集型任務，例如檔案上傳時的雜湊計算、大數據量的排序與過濾、圖片壓縮。作者以一個實際案例說明：上傳檔案時頁面卡死，原因是雜湊計算與壓縮全部在主線程上執行，其餘任務被迫排隊。

2026年的解法組合：從讓出執行權到背景運算

文章提出的解法中，第一項是scheduler.yield()。這是瀏覽器Prioritized Task Scheduling API中的非同步方法，作用是主動把主線程控制權交還瀏覽器，讓其先處理使用者輸入與渲染等高優先級任務，再回來繼續執行原程式碼。與傳統以setTimeout切分任務的做法相比，差異在於scheduler.yield()會保留任務優先級，setTimeout則會把任務排到佇列後方，不保證及時恢復執行。

第二項是Web Workers。Worker運行於獨立的作業系統執行緒，擁有自己的記憶體空間與事件循環。作者以數據對比：一個耗時兩秒的運算放到Worker中執行，主線程的消耗為零。適用場景包括檔案雜湊計算、數據壓縮、圖像處理與大規模資料的排序過濾。

文中另外兩項解法涉及框架層與規範層的調整，原文在React相關段落之後的內容未完整收錄於來源節錄，本臺不予推測補述。

規範進展與訊源對照

值得對照的是時間點。文章開頭提到，WHATWG已在2026年清理Fetch同步標誌的殘留，這與同步網路請求長期阻塞主線程的歷史問題相關。此一規範動態屬於公開可查證的瀏覽器標準進展，與文中「前端效能優化戰場轉移」的判斷互為註腳。

同樣涉及瀏覽器能力擴充的還有W3C孵化中的WebMCP標準，其方向是讓網頁向前端宣告可用工具，顯示瀏覽器平臺本身仍在快速疊代，主線程資源的競爭只會更複雜。

作者在文中另有一個觀點性表述：當AI智慧體能在一秒內生成完整的3D網頁時，「能跑」與「能流暢地跑」之間的差距，正在成為前端工程師的差異化能力。此為作者個人判斷，非可驗證的量測結論。標題中「90%的前端都忽略了主線程」同樣屬修辭性說法，來源頁面未提供調查依據。截至發稿，該文閱讀量約31次，屬於傳播初期的技術長文。

可核實與不可核實的邊界

綜合來看，文中可核實的部分包括：60Hz下每幀16.7毫秒的幀時間、約10毫秒的JavaScript預算、50毫秒的長任務門檻、INP作為Core Web Vitals核心指標的地位，以及transform與opacity兩項屬性不觸發重排的既有結論。這些均可由Chrome開發者文件與Web指標規範交叉驗證。

至於具體優化案例的實測數據，例如主線程佔用時長下降幅度、上傳卡死案例的還原過程，原文以「真實案例」稱之，未附可複現的量測環境，讀者宜將其視為經驗性佐證而非嚴格的對照實驗。效能優化的實際收益，仍須以各專案自身的Performance面板量測為準。