分析 Runtime Activities

Performance 面板會盡量把瀏覽器運作過程細分為各種 activity，找出真正卡住主執行緒（Main Thread）的那一個就能對症優化。

建構視角的對應章節：執行期偵錯

概覽#

Performance 面板涵蓋的資訊量很大，本章聚焦在「哪個 activity 卡住了主執行緒」的分析方法。

第一次面對密密麻麻的效能報告會無從下手，幾個小技巧可以提升分析效率：

瀏覽器快取與外掛都會干擾測量，每次分析時應使用乾淨環境，例如開無痕視窗、建立新使用者，確保沒有額外套件偷偷執行；也可以用 Network 面板手動清除快取或停用快取。

「過早的優化是萬惡的根源。」開發初期難以確認真正瓶頸，動手前先設定明確目標（例如：解決點某按鈕後畫面卡一下的問題），才能讓分析更有方向。錄製過程也應盡量縮短，避免額外點擊或捲動觸發無關 JavaScript。

當瀏覽器來不及在 16 毫秒內產生下一幀，多半是主執行緒太忙。找出忙碌來源就是分析重點。

點擊 Main 中的任意區塊（activity），或在時間軸上拖曳一段範圍，下方會展開四個分頁：

預設以 Self Time 排序，方便找出總執行時間最長的 activity。例如錄製剛載入時的效能，常會發現 Recalculate Style 因為觸發次數多，加總後超過其他 activity 成為最高項。

在 filter 旁的 Grouping 選單可改變分組方式，例如以 Category 分組會把同色系 activity 視為一組。

右上角可以展開 Heaviest stack，顯示一連串執行時間最長的觸發鏈，與排序最上面的 activity 對應。

從 Root activity 開始依觸發關係展開，外層 activity 的執行時間是其下所有子 activity 的總和。

預設以 Total Time 排序，可看出耗時最長的 Root activity。例如某次紀錄中最長的 Root activity 可能是某個 Event: dbclick，展開後會看見它觸發的所有後續 activity。

預設以觸發時間排序，左側多了一欄 Start Time。比較特別的是可以同時用執行時間與類型過濾，例如「只顯示執行 15 毫秒以上的 Script」。

面板上方開啟 Memory 後，紀錄會帶上記憶體用量。點擊記憶體圖表上的時間點會自動跳到對應的 activity，方便檢視「用量飆升前發生了什麼」。

Memory 面板的 Allocation Sampling 紀錄的是 GC 後的結果，因此完整被回收的 function 不會出現；反過來看，能凸顯每個 function 中無法被 GC 的部分。它同樣提供 Chart、Bottom Up、Top Down 三種模式。

Performance 面板會在 Task 上以紅色三角形標記 Long Task，並用紅色斜線標出超過 50 毫秒的部分。為什麼是 50 毫秒可參考 Web Vitals 一章關於 TBT 的說明。

打開示範頁面後按下 GO，等動畫恢復跳動再停止錄製，就能在 Performance 面板看到一連串可分析的 activity，並照前述步驟逐一檢視 Bottom-Up、Call Tree、Event Log。

把 Performance 面板的資訊一一拆解後，效能分析其實有跡可循。找到可疑的 activity，再對症下藥，比起想到什麼就改什麼有效率得多。