iT邦幫忙

第 12 屆 iThome 鐵人賽

DAY 25
1
Modern Web

你所不知道的各種前端 Debug 技巧系列 第 25

[Day 25] Performance - Analyze Runtime Activities

  • 分享至 

  • xImage
  •  

在 Performance 面板中,為了讓開發者方便優化網頁效能,會盡可能把瀏覽器運作的過程分類為各種 Activities,開發者找出造成效能瓶頸的 Activity 就能針對該部分進行優化。

概覽

在 Performance - Overview 一文中,簡單的介紹了 Perfromance 面板提供了哪些資訊,本文的重點在於分析瀏覽器執行過程中,究竟是甚麼 Activity 卡住了主線程(Main),造成效能問題。

 

準備

第一次使用 Performance 面板時一定會看著密密麻麻的效能報告不知所措,為了盡可能的提升尋找問題的效率,有幾個小技巧可以使用:

保持環境整潔

瀏覽器的快取、Extension 都會在分析效能問題造成干擾,每次分析時應該使用乾淨的環境,例如開啟無痕模式、建立一個新的使用者來確保沒有額外的套件偷偷執行,另外也可以利用 Network 面板手動清除瀏覽器的快取或是直接取消快取。

鎖定目標

為什麼要分析效能?有句話說:「過早的優化是萬惡的根源。」其中一大原因就是在開發的初期很難確定真正的效能問題、瓶頸,因此在開始優化之前,先訂下明確的目標,例如解決點擊某按鈕時畫面會卡一下的問題,能有效降低優化的難度。

確定目標後就能著手開始分析,記錄過程中要盡可能的縮短效能記錄的時間,且避免進行額外的動作如點擊、Scroll 等等以防觸發額外的 JavaScript 行為。

 

主線程 Main

瀏覽器來不及在 16 毫秒內產生下個畫面就會卡卡的,其大多都是因為主線程過於忙碌,因此找出忙碌的來源就是效能分析的重點。

記錄一段效能後,點擊 Main 裡面的任意區塊(Activity)或是在時間線中拖曳會展開下方的詳細資訊表,其中會有四個分頁:

  • Summary - 顯示該 Activity 的執行時間還有時間內觸發其他 Activities 的時間比例
  • Bottom-Up - 將同一種 Activity 合併 (一種 Activity 可能執行多次)
  • Call Tree - 以觸發關係從上到下顯示 Activities,最外層稱為 Root activity,就是一連串 Activities 的起點
  • Event Log - 以時間順序顯示 Activities

 

Bottom-Up

一個 Activity 可能會執行多次,這個分頁中會以一個 Function 或是 Activity 類型分類,預設以 Self Time 排序,可以找出總執行時間最長的 Activity。

此圖中顯示 Recalculate Style 執行了最多時間,因為是頁面剛啟動時記錄的,觸發多次 Recalculate Style,加總起來就超過了其他 Activities。

Grouping

在 Filter 旁有 Grouping 選單,可以選擇其他群組方式,例如以 Category 分類就會把同一個顏色的 Activities 變為一組。

Heaviest stack

右上角可以展開 Heaviest stack,會顯示執行時間最長的一連串觸發過程,和排序後最上面的那幾個 Activities 相同。

 

Call Tree

從 Root activity 開始以觸發關係顯示 Activities,最外層的 Activity 執行時間是展開後所有 Activities 執行時間的總和,直到 Root activity 觸發的 Activities 都執行完 Root activity 才會結束。

Call Tree Tab 預設用 Total Time 來排序,可以看出執行時間最長的 Root activity,以圖表來看就是 Task 下一層中最長的 Activity。例如上圖中執行時間最長的就是左邊的 Event: dbclick,打開 Heaviest stack 也會顯示這個結果。

 

Event Log

預設以觸發時間排序,也就是圖表中由左到右依序顯示,可以看到左邊多了一欄 Start Time,比較特別的是可以用執行時間和類型來過濾 Activities,例如只顯示執行 15 毫秒以上的 Script。

 

Memory

在面板上方打開 Memory 選項會記錄 Memory 的資訊,在 Memory 圖表中點擊時會自動標記對應時間點的 Activity,可以看看用量飆升前發生了什麼事情。

Allocation sampling

在 Memory 面板中可以用 Allocation sampling 記錄 Function 的Memory 用量,不同於 Performance 面板是記錄即時的 Memory 用量變化,Allocation sampling 產生的是 GC 後的結果,因此完整被 GC 的 Function 不會留在結果內,反過來說,可以看出每個 Function 中無法被 GC 的用量。

Allocation sampling 提供了三種分析模式 chartBottom UpTop Down,和 Performance 面板是不是有似曾相識的感覺呢?

實際範例

打開 Demo 頁面 Analyze Runtime Activities,開始記錄後按下 GO,等愛心恢復跳動再停止,觀察 Performance 內的結果。

有注意到紅色三角型標記嗎? Performance 面板會很貼心的標註 Long task,並把 Task 中超過 50 毫秒的部分以紅色斜線標記,至於為什麼是 50 毫秒,可以參考 Performance - Web Vitals 中的 TBT。

結語

Performance 系列到此告一段落,基本上把面板中顯示的資訊都解釋了一遍,看過這系列的文章後,是否想要來點前端優化了呢?


上一篇
[Day 24] Performance - Analyze Memory
下一篇
[Day 26] Cookies - SameSite Attribute
系列文
你所不知道的各種前端 Debug 技巧30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

1 則留言

0
Dylan
iT邦新手 1 級 ‧ 2020-10-28 22:14:41

Demo 網址「Analyze Runtime Activities」壞了 QQ

shizuku iT邦新手 5 級 ‧ 2020-10-28 22:21:17 檢舉

我要留言

立即登入留言