關於 Chrome DevTools Performance 的使用與分析

語言: CN / TW / HK
時間 2022-10-10 12:15:28
主題:

關於 Chrome DevTools Performance 的使用與分析

為什麼使用 Performance ?

事物的存在必然有它的原因，Performance存在的原因是什麼呢？

web應用開發後最終是要提供給使用者，使用者滿意開發者才能到得相應的回報。讓使用者滿意說容易也並不容易，首先靠外在(設計、運營)去吸引眼球，再通過內在(穩定、流暢)去吸引人心。在web應用開發中我們將內在量化概稱為效能。一個人內在是否充盈會影響Ta是否受歡迎，那一個web應用效能是否達標則會影響使用者的滿意度以至於影響到公司以及開發者自身的持續發展。

所以，作為開發者，即便為了自己的可持續發展，也要把Performance這塊搞一搞。至於怎麼搞，剛好Chrome有個除錯技巧 ——devTools Performance，下面就來學習一下

準備

開始前先進行一些相關知識拓展。有助於檢視後續內容時能更好的理解。

RAIL 模型

uc1IWVOW2wEhIY6z4KjJ-2.png

RAIL模型是瞭解效能的基礎，是一種以使用者為中心的效能模型，字面意思即1.Response響應、2.Animation動畫、3.Idle空閒、4.load載入 ，代表了Web 應用生命週期的四個方面，使用者對此有不同的效能期待。這些效能期待是有目標和準則的，結合著4個方面，即成為我們優化效能的參考指標。所以後面的除錯中，當獲取了資料卻無從下手時，可以參考 RAIL 模型的相關內容作為對比。判斷效能是否異常，異常出現在哪裡。

但是也要注意因為網路條件和硬體的不同，使用者對效能延遲的感知也有所不同。最終還是要根據自身實際情況做判斷，適合的才是最好的。這裡不展開討論，詳情可以檢視使用 RAIL 模型衡量效能。

面板介紹

總體分為 4 塊區域：Controls、Overview、Thread、Details

Controls 控制

image-20220725093032417.png

  • 開始記錄、開始並重新載入記錄、停止記錄
  • 匯入、匯出記錄
  • Screenshots 截圖：預設勾選，每一幀都會截圖
  • Memory 記憶體消耗記錄：勾選後可以看到各種記憶體消耗曲線

Overview 概覽

image-20220725092937244.png

  • 時間軸：整個記錄過程的時間標註

  • FPS：根據chrome官方文件和網上其他參考資料表示，除了 CPU 和 NET 外，還有一行 FPS，紅色線段代表FPS非常低，而綠色條越高，FPS 越高。但是在實踐了多臺裝置後發現，新版本的chrome沒有顯示FPS標識，只有幀率低的時候會顯示紅色條，綠色條始終沒有看到。官方文件基於chrome 59版本進行說明，並沒有更新關於此處變化的說明。 暫時理解為，有紅色條說明 FPS 低，沒有紅色條 FPS 正常。此處作為一個問題點，之後會再繼續探究。如果有人知曉也麻煩告知一下。

  • CPU、NET：CPU、NET隨時間的變動。CPU 圖表與 performance 面板底部 summary 選項卡中的顏色對應。CPU 圖表充滿顏色意味著CPU在記錄期間處於一個滿載的狀態。當看到 CPU 長時間處於滿載狀態，就是告訴你這裡可能需要優化了。

    NEW 在這篇 performance 資料中不做討論了，如果需要除錯 NET 可以使用 DevTools 的 Network 面板。

  • 截圖：逐幀截圖，除錯參考用。

Thread 執行緒

image-20220725131901285.png

詳細的分析某些任務的詳細耗時，從而定位問題。

  • Network：可以看出網路請求的詳細情況。除錯 network 可以使用 DevTools 的 Network 面板。

  • Frames：

    image-20220725131531460.png

    表示每幀的執行情況。將滑鼠懸停在其中一個綠色方塊上。DevTools 會顯示特定幀的處理時長。根據60 FPS的標準 每幀的時間應該約為16.7ms。通過這個可以判斷 FPS 是否異常，以及那些幀存在問題。

  • Timings：點選開始並重新載入記錄時會顯示此行，用於除錯應用的首屏效能。

    image-20220725131030521.png

    • FP（first paint）：首個畫素開始繪製到螢幕上的時機，例如一個頁面的背景色
    • FCP（first contentful paint）：開始繪製內容的時機，如文字或圖片
    • LCP（Largest Contentful Paint）：視口內可見的最大內容元素的渲染時間
    • FMP（First Meaningful Paint）：首次有意義的繪製
    • DCL（DOMContentLoaded）：表示 HTML 已經完全被載入和解析
    • L（Onload）:頁面所有資源載入完成事件

  • Main：

    image-20220725132213739.png

    可以分析每個任務的耗時、呼叫棧等資訊。是效能除錯比較重要的部分。X軸表示時間，Y軸表示事件。每一個條形代表一個事件，條形越長，消耗時間越長。當看到圖形堆疊，表示同一時間處理事件較高。可能會導致效能問題。面板中會有很多的 Task，如果是耗時長的 Task，其右上角會顯示紅色三角，這個時候就可以選中標紅的 Task，定位到耗時函式，然後針對性去優化。

  • Raster：光柵化執行緒池，用來讓 GPU 執行光柵化的任務。

  • GPU：可以直觀看到何時啟動 GPU 加速。

  • Compositor：合成執行緒的執行記錄，用來記錄 html 繪製階段 (Paint)結束後的圖層合成操作。

Details 詳情

  • Summary： 各型別事件所消耗時長的餅狀圖總覽。通過對比各項時長，可以判斷是否存在異常。通常整體當中的Idle佔比較多是比較期望的情況。如果其他內容佔比較多，我們就可以去看一下它佔比多的原因。

    • 黃色(Scripting)：JavaScript 執行
    • 紫色(Rendering)：樣式計算和佈局，即重排
    • 綠色(Painting)：重繪
    • 灰色(other)：其它事件
    • 白色(Idle)：空閒

    image-20220725095724938.png

  • Bottom-Up：表示事件時長排序列表，可以檢視花費最多時間的活動。

    • Self Time：指除去子事件這個事件本身消耗的時間
    • Total Ttime：這個事件從開始到結束消耗的時間（包含子事件）

    image-20220725095744238.png

  • Call Tree：表示事件呼叫順序列表，可以檢視導致最多工作的根活動

    image-20220725095832263.png

  • Event Log：表示事件發生的順序列表，可以看到事件的開始觸發時間 start time，根據記錄期間的活動順序檢視活動，右邊有事件描述資訊

    image-20220725095852564.png

使用與分析

注意事項- 無痕模式：使用無痕模式開啟頁面，避免瀏覽器擴充套件外掛對效能除錯產生干擾。

  • 幀速率：開啟幀速率視窗便於觀察，DevTools 點選右上角三個點 → more tools → Rendering → 勾選Frame Rendering Stats。勾選後頁面的左上角會顯示實時幀資料。
  • 截圖：勾選 screenshots 在錄製時捕獲每一幀的螢幕截圖。便於除錯時回看頁面的展現情況。
  • cpu節流：鑑於除錯裝置cpu效能可能較高。為了模擬低配裝置可以將 cpu throtting 設定為 4×slowdown，這樣執行速度會慢4倍。
  • 以下示例 於 chrome 103版本除錯並截圖

使用

  1. 使用Google測試頁面進行測試，以無痕模式開啟頁面，開啟 DevTools，切換至 Proformance 面板。可以看到頁面中元素並不多，執行還是非常流暢的。

    animation.png

  2. 我們將方塊數新增至 300。

image-20220722152658349.png

可以看到頁面幀率已經下降到19FPS，藍色方塊移動的動畫肉眼可見的卡頓。

接下來我們用 DevTools Performance 記錄一下頁面此時執行時效能。

  • 點選 DevTools Performance 左上角圓點 或者 快捷鍵 coommand+E 開始記錄。
  • 等待幾秒，點選 stop 結束錄製，DevTools 會處理資料並展示在 Proformance 面板中。

image-20220722153917116.png

分析

這個記錄的結果中資訊很多，通過查閱官方文件，和其他社群參考得知，通常情況下會判斷以下幾點關鍵資訊

  • 幀速率：左上角 Frame Rate 顯示的FPS資料，顯示19fps，明顯低於60fps的預期。說明一定存在效能問題，並且會影響到使用者體驗。但是還不知道問題在哪，需要繼續排查。

  • CPU：這裡可以看到 CPU 充滿了顏色，處於一個滿載的狀態，並且參照底部 Summary 發現 紫色區域佔比很大，渲染佔用了非常多的時間。所以問題的大概方向是出在渲染。

  • Main：

    前面有提到，Main 是 performance 除錯中比較重要的部分，而且這部分帶給我們的資訊也比較多，那麼我們詳細看下這部分。

    通過在 Overview上單擊、按住和拖動滑鼠來放大單個Animation Frame Fired 事件，注意Animation Frame Fired 事件右上角的紅色三角形。當看到紅色三角形時，表示可能存在與此事件相關的問題的警告。

    點選 Animation Frame Fired 並參照底部 Summary 現在展示的資訊。發現會有一個警告，並且提供了相應的連結 app.js:95 。單擊可以跳轉到原始碼中的相關行。這個警告沒有體現具體問題，所以我們先繼續往下看。

    image-20220725104559594.png 在 app.update 下方還有很多紫色事件有紅色三角，點選其中一個紫色事件。

    image-20220725105248961.png

    可以看到有一個關於強制迴流的警告。

    image-20220725105307733.png

    我們點選 app.js:70 跳轉到強制迴流的程式碼行。這裡有展示每行程式碼的耗時。

    image-20220725105918834.png

發現了問題的所在，此處程式碼消耗時間明顯遠高於其他行。

此處程式碼的問題在於，在每個動畫幀中，它會更改藍色方塊的樣式，然後查詢每個方塊在頁面上的位置。因為樣式變了，瀏覽器不知道每個方塊的位置是否改變了，所以它必須重新佈局方塊來計算它的位置。

接下來我們就可以考慮如何用盡可能更好的方法去解決這個問題。關於相關優化，這裡不展開討論。可以檢視避免強制同步佈局來了解相關優化資訊。

總結

以上根據 google 示例的一個除錯來了解 performance 的大概使用和資訊關鍵點的分析。實際生產中，問題可能不同，但是隻要按照思路針對問題表現去抽絲剝繭，總能調查根本原因，然後逐一調查並處理，直到修改到符合期望。

示例的效能問題是由於迴流導致的，影響效能的原因不限於此，還可能有多種多樣的問題，例如 long task 帶來的阻塞等。好的工具會幫助你提升效率，但是最重要的還是要擁有一個好的開發習慣以及增強自身的總體技術水平，儘量在源頭上減少甚至避免問題的出現。

其他

我們在開啟DevTools的時候會發現除了Performance，還有一個名稱類似的 Performance Insights 。

這是一個於102版本釋出的實驗功能，目的在於解決使用 Performance 時的以3 個痛點：

  • 資訊太多。通過重新設計的 UI，效能洞察面板簡化了螢幕上顯示的資料，僅顯示相關資訊。
  • 很難區分用例。效能洞察面板支援用例驅動分析。它目前僅支援頁面載入用例，未來會根據反饋提供更多功能（例如互動性）。
  • 需要深入瞭解瀏覽器如何有效使用的專業知識。效能洞察面板突出顯示洞察面板中的關鍵洞察，並提供有關如何修復它的可操作反饋。

詳情可以查閱 效能洞察：獲取有關您網站效能的可操作洞察

「」