看懂 Performance 面板的每個區域：Live Metrics 首頁、時間軸總覽、各軌道、火焰圖、底部分頁與 Insights 側欄。
正確設定錄製環境（CPU / 網路節流、截圖），並知道為什麼要這樣設。
依照三套固定流程，分別診斷 LCP、INP 與 CLS 問題，並定位到具體的資源、元素或程式碼。
搭配 Network 面板讀懂瀑布圖的每個階段與優先權。
本章是操作手冊，建議一邊開著 Chrome（建議使用最新的穩定版或 Canary）一邊閱讀。DevTools 介面每幾個月會有調整，若某個按鈕名稱略有不同，請以功能描述為準。所有截圖式的說明都以文字與示意圖呈現，方便你對照自己的畫面。
開啟面板：Live Metrics 首頁
按 （macOS：）開啟 DevTools，切到 Performance 分頁。在尚未錄製任何東西時，你會看到 Live Metrics 畫面，它就是一個即時的 Web Vitals 儀表板：
三張指標卡：目前這個分頁的本地 LCP、CLS、INP，並以綠 / 橘 / 紅標示良好 / 待改善 / 不佳。這些數值會隨你操作頁面而更新——非常適合重現「只有在某些操作下才出現」的 INP 或 CLS 問題。
LCP 元素：卡片下方顯示 LCP 元素的節點，滑鼠移上去會在頁面上高亮。展開卡片可看到 LCP 的四個子部分（）。
Interactions 與 Layout shifts 面板：列出每一次互動（目標元素、類型、三個子部分的時間）與每一次版面跳動（分數、元素）。可清除重來。
Field data（CrUX）：右側可開啟「Field metrics」，輸入網址後 DevTools 會抓取 CrUX 的 28 天 p75 數據並排顯示，還會提示「本地與真實數據差異很大」的情況，並依真實使用者的裝置與網路分布建議你應該用哪一級的 CPU 與網路節流。
Environment settings：直接在這裡設定 CPU throttling、Network throttling，以及是否模擬行動裝置。
用無痕視窗或乾淨的 profile：瀏覽器擴充功能會注入腳本、佔用主執行緒，嚴重干擾量測。
開啟 CPU 節流：桌機 CPU 比中階手機快 4–10 倍。Performance 面板提供 4x / 6x / 20x 與「Calibrated」（依你的機器校準出「低階行動裝置」與「中階行動裝置」的等效倍率）。行動版問題請至少用 4x。
開啟網路節流：常用 Slow 4G（或 Fast 4G）。注意這是在瀏覽器層模擬，無法完全反映真實無線網路的封包遺失與 RTT 抖動。
錄製一段 trace
面板左上角有兩個錄製按鈕：
Record（圓點）：開始錄製目前頁面的執行期行為。用於 INP（錄製時要親手互動）、動畫、捲動卡頓。按 Stop 結束。
Record and reload（重新整理圖示）：重新載入頁面並錄製整個載入過程，載入穩定後自動停止。用於 LCP、FCP、載入階段的 CLS 與長任務。
齒輪圖示展開「Capture settings」：
Screenshots：錄製逐幀截圖，形成 filmstrip，可用來目視確認 LCP 元素何時出現、版面何時跳動。建議開啟。
Memory：記錄 JS heap、節點數等，除錯記憶體問題時才開。
Disable JavaScript samples：關掉 JS 呼叫堆疊取樣，降低錄製開銷，但火焰圖只剩瀏覽器層級事件。一般不勾。
Enable advanced paint instrumentation (slow)：記錄圖層與繪製細節，除錯 paint / composite 問題時才開。
Enable CSS selector stats (slow)：統計哪些選擇器在樣式重算中最耗時。
錄好的 trace 可用右上角的「儲存」匯出為 ，在 code review 或回報 bug 時附上，對方用「載入」即可看到完全相同的畫面。
版面導覽
max width=
火焰圖的顏色語義
C2.2cm L3cm L8.4cm 顏色 & 類別 & 典型事件
黃 & Scripting & Evaluate Script、Function call、Event、Timer fired、XHR / fetch 回呼、GC
紫 & Rendering & Recalculate style、Layout、Pre-paint、Hit test；標紅三角的 Layout 通常是強制同步版面（forced reflow）
綠 & Painting & Paint、Composite layers、Image decode、Rasterize
藍 & Loading & Parse HTML、Parse stylesheet、Send request、Receive data
灰 & Task / System & 任務外框；長任務會有紅色標記
淺灰 & Idle & 主執行緒閒置
操作技巧
縮放與平移：在火焰圖上用 / 縮放、/ 平移；或在總覽列拖曳選取範圍。雙擊一個事件會縮放到它。
Breadcrumbs：每次縮放會在總覽上方留下路徑，可快速跳回上一層。
隱藏 / 排序軌道：對軌道名稱按右鍵可隱藏或調整順序；也可對火焰圖中的函式按右鍵「Hide function」或「Hide children」讓圖更乾淨。
點選事件 \(\rightarrow\) Summary：顯示時間、來源檔案（可點擊跳到 Sources 面板對應行）、以及對 Layout 事件的「Layout forced」警告。
Ctrl / Cmd + 點選 Network 請求：在 Network 軌道點一個請求，Summary 顯示其優先權、各階段時間、大小與 initiator。
Annotations：對任何事件按右鍵可加上文字標籤、在兩個事件之間畫連線、或標記一段時間範圍，並會隨 trace 一起匯出，適合在團隊內溝通。
Insights 側欄：把 Lighthouse 的建議搬進 trace
Insights 側欄整合了 Lighthouse 的稽核邏輯，但最大的價值在於與時間軸連動：把滑鼠移到一個 insight 上，面板會高亮相關事件、畫出關鍵路徑或子部分覆蓋層；點擊則會縮放到該區域。常用項目：
L3.4cm L10cm Insight & 它告訴你什麼、該怎麼做
LCP breakdown（LCP by phase） & 四個子部分各佔多少（）；開啟 Field data 時會並列 CrUX 的 p75 子部分。看最長的那段。
LCP request discovery & 三個檢查：LCP 圖片是否有 、是否可在 HTML 中被發現、是否沒有 lazy-load。任一項打叉就是明確的修法。
Render blocking requests & 列出阻塞首次繪製的 CSS / JS 與各自造成的延遲估計。
Network dependency tree & 從 HTML 出發的關鍵請求鏈（A 載入 B、B 再載入 C），鏈越長 LCP 越晚。目標是縮短、扁平化。
Document request latency & HTML 請求本身的問題：重導、TTFB 過高、未壓縮。
Font display & 有沒有字型阻塞文字顯示（FOIT），建議 。
Image delivery & 圖片格式、尺寸、壓縮的可節省位元組估計。
INP breakdown & 錄製期間最慢的互動及其三個子部分；需在錄製時有實際互動。
Layout shift culprits & 最大的 CLS 叢集、其中每次跳動的元素、與可能的原因（無尺寸圖片、注入的 iframe、字型變化、動畫）。滑過每次跳動會顯示前後截圖動畫。
Third parties & 各第三方來源在主執行緒與網路上的成本排名。
Forced reflow & 哪段程式碼在讀取版面屬性時觸發了同步版面計算，含呼叫堆疊。
DOM size & 節點數、最大深度、最多子節點的元素。
Legacy JavaScript / Duplicated JavaScript & 為舊瀏覽器多打包的 polyfill / transpile 成本；重複打包的模組。
Use efficient cache lifetimes & 快取壽命過短的靜態資源（）。
實戰流程 A：診斷 LCP
在 Live Metrics 頁面設定 CPU 4x、Slow 4G，勾選 Screenshots，按 Record and reload。
錄製結束後，在 Timings 軌道找到 LCP 標記。點它：Summary 會顯示 LCP 元素（可 hover 在頁面上高亮）、時間與相關資源 URL。
開啟左側 Insights \(\rightarrow\) LCP breakdown：看四個子部分。
TTFB 大：切到 Network 軌道第一個請求，看等待時間；回到、的手法。
資源載入延遲大：在 Network 軌道找到 LCP 圖片的請求條，看它何時開始。往左看在它之前主執行緒在做什麼（通常是一大塊黃色的 Evaluate Script——JS 才插入圖片）或 CSS 才剛解析完（背景圖）。同時看 LCP request discovery 的三個勾。
資源載入時間大：點該請求，看 Summary 的大小、優先權（Priority 應為 High）、協定。用 filmstrip 對照圖片何時出現。
元素渲染延遲大：看 LCP 資源 之後、LCP 標記之前，主執行緒是否被長任務（黃色）佔住，或 Render blocking requests 是否還有東西沒到。
檢查 Network dependency tree 與 Render blocking requests，把不該在關鍵路徑上的東西移走。
修改後用同樣設定再錄一次比較。變異是正常的，建議至少錄 3 次取中位數。
實戰流程 B：診斷 INP
設定 CPU 4x（或 Calibrated 的中階行動裝置）。按 Record（不是 reload）。
親手操作你懷疑會慢的互動：點按鈕、開選單、在輸入框打字、切換分頁。也試著在頁面還在載入時就互動——真實使用者不會等。按 Stop。
看 Interactions 軌道：每次互動一條橫條，超過 200 ms 的會標示警告。橫條分成三段（可 hover 看）：輸入延遲 / 處理時間 / 呈現延遲，兩端的細線（whiskers）代表輸入延遲與呈現延遲。
點選最長的互動，同時對照它正下方的 Main 軌道：
輸入延遲長：互動開始時主執行緒已經有一個灰色 Task 在跑（往往是載入期的 Evaluate Script、第三方 Timer fired、或前一次互動還沒處理完）。找出那個任務是誰的。
處理時間長：黃色 Event: click / keydown 之下的 Function call 就是你的處理器。點它，Summary 有檔案與行號；切到 Bottom-Up、Group by Activity，看哪個函式自身時間最多。框架的 re-render 會顯示為一大串框架內部函式，此時 Group by URL 可快速看出是框架還是你的程式碼。
呈現延遲長：處理器結束後出現大塊紫色（Recalculate style / Layout）與綠色（Paint），代表 DOM 變動太大或觸發了昂貴的版面計算。若 Layout 帶紅三角，Summary 會指出是哪一行讀了版面屬性（forced reflow）。
開啟 Insights \(\rightarrow\) INP breakdown 確認三段比例；在 Live Metrics 的 Interactions 列表也可看到同樣資訊。
修法回到：拆長任務、視覺回饋先行、把渲染變便宜。
實戰流程 C：診斷 CLS
Record and reload（載入期跳動）或 Record 後捲動、互動（延遲載入內容的跳動），建議開 Screenshots。
看 Layout shifts 軌道：每次跳動是一個小區塊，被歸在同一 session window 的會以叢集標示。點叢集或單次跳動，Summary 列出分數、移動的元素（hover 高亮）、前後位置。
開啟 Insights \(\rightarrow\) Layout shift culprits：直接列出最大叢集中的每次跳動與可能原因；滑過會播放前後截圖的動畫，一眼看出「誰把誰推開」。
對照 filmstrip 與 Network 軌道：跳動發生的瞬間是哪個資源剛載完（圖片？字型？廣告 iframe？）。
修法回到的成因對策表。修完後用 Live Metrics 的 Layout shifts 面板快速驗證，不必每次錄 trace。
搭配 Network 面板
Performance 面板的 Network 軌道適合看「與主執行緒的時間關係」，但細節在 Network 面板更完整：
瀑布圖（Waterfall）各段：Queueing（等待可用連線 / 優先權排隊）、Stalled、DNS Lookup、Initial connection、SSL、Request sent、Waiting for server response（TTFB）、Content Download。點請求 \(\rightarrow\) Timing 分頁可看精確數字。若有 Service Worker，還會多出 Request to ServiceWorker、ServiceWorker preparation、respondWith 等段。
Priority 欄（右鍵表頭開啟）：Highest / High / Medium / Low / Lowest。LCP 圖片應為 High；若是 Low 就是 的用武之地。
Protocol 欄：h3 / h2 / http/1.1。
Size 欄：顯示 、、、，或實際傳輸大小；下方灰字是解壓後大小。304 會顯示很小的傳輸量。
Initiator 欄：誰發起這個請求；hover 顯示呼叫堆疊。用來追「為什麼 LCP 圖片這麼晚才被請求」。
Disable cache：模擬首次造訪。Preserve log：跨導覽保留記錄。Block request URL：測試某第三方移除後的影響。
篩選列可用 、、、 等語法。
其他相關工具
Lighthouse 面板：一鍵產生實驗室報告，適合快速盤點；其 insights 與 Performance 面板一致，Lighthouse 12 起可直接「View trace」跳到 Performance 面板。
Rendering 側欄（More tools \(\rightarrow\) Rendering）：Paint flashing（哪些區域在重繪）、Layout Shift Regions（跳動區域藍色閃爍）、Frame Rendering Stats（FPS 與 GPU）、Scrolling performance issues。
Performance monitor（More tools）：即時折線圖：CPU、JS heap、DOM 節點數、每秒 layout / style recalc 次數。找記憶體洩漏與版面抖動很好用。
Coverage（More tools）：顯示每個 JS / CSS 檔有多少位元組在載入期間未被執行 / 使用，是 code splitting 的依據。
Application \(\rightarrow\) Back/forward cache：測試頁面是否能進入 bfcache 並列出原因（）。
Web Vitals 擴充功能：在頁面角落常駐顯示三項指標，並可在 Console 印出 attribution；與 Live Metrics 功能重疊，但方便一般瀏覽時觀察。
課堂實作
挑一個內容豐富的公開網站（新聞、電商）。設定 CPU 4x、Slow 4G、Screenshots，Record and reload。完成後回答：(1) LCP 是多少、元素是什麼、四個子部分各多久？(2) 有幾個 render-blocking 請求？(3) 最長的任務多長、是誰的程式碼？(4) 有沒有版面跳動？哪個元素？把 trace 存檔。
用實作 3-2 的「建立 20,000 個 li」頁面（或任何有慢互動的頁面），CPU 4x，Record，點擊，Stop。在 Interactions 軌道找到該互動，記錄三個子部分；在 Main 軌道找到對應的 Function call，用 Bottom-Up 找出自身時間最多的函式；點擊來源連結跳到 Sources 面板。然後把程式碼改成分批 + yield 版本，再錄一次，比較 Interactions 軌道的變化。
在 Live Metrics 開啟 Field metrics，輸入一個流量足夠的網站。比較本地與 CrUX 的 LCP 差距，並依 DevTools 的建議調整 CPU / 網路節流後再錄一次，看本地數字是否更接近真實 p75。討論：為什麼還是會有差距？（裝置分布、地理位置、快取狀態、登入狀態……）
火焰圖中一個 Layout 事件帶有紅三角，Summary 顯示「Forced reflow is a likely performance bottleneck」。這代表什麼？請寫出一段會造成這種情況的程式碼，並修正它。
Interactions 軌道顯示某次點擊的輸入延遲 180 ms、處理 30 ms、呈現 20 ms。你會先去看 Main 軌道的哪個位置？可能的成因是什麼？
為什麼「Record and reload」適合看 LCP，而 INP 必須用「Record」並親手互動？
為什麼 DevTools 建議依 CrUX 數據調整 CPU 節流倍率，而不是統一用 4x？
Network 面板中某圖片的 Priority 是 Low、Initiator 是某個 JS 檔。這兩個資訊分別對應 LCP 的哪個子部分問題？該怎麼修？
Performance 面板的入口是 Live Metrics：即時 LCP / INP / CLS、LCP 元素、互動與跳動列表、CrUX 對照與環境建議。
錄製前先設定 CPU 與網路節流、開啟 Screenshots，並用乾淨的瀏覽器環境。
讀圖三要素：Timings 找指標時間點、Main 火焰圖看主執行緒在做什麼（黃 scripting、紫 rendering、綠 painting、藍 loading、紅三角長任務）、Network 看資源何時開始與結束。
Insights 側欄把 LCP 子部分、INP 子部分、CLS 兇手與各種稽核直接疊在時間軸上，是最快的定位工具。
三套流程：LCP 看 Timings + LCP breakdown + Network；INP 看 Interactions + 正下方的 Main + Bottom-Up；CLS 看 Layout shifts + culprits + filmstrip。