關於 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，性能洞察面板簡化了屏幕上顯示的數據，僅顯示相關信息。
  • 很難區分用例。性能洞察面板支持用例驅動分析。它目前僅支持頁面加載用例，未來會根據反饋提供更多功能（例如交互性）。
  • 需要深入瞭解瀏覽器如何有效使用的專業知識。性能洞察面板突出顯示洞察面板中的關鍵洞察，並提供有關如何修復它的可操作反饋。

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

「」