Analyze runtime performance

運行時性能是您的頁面在運行時的表現，而不是加載。 就 RAIL 模型而言，本文介紹的方法對于分析頁面的響應、動畫和空閑階段非常有用。

在隱身模式下打開谷歌瀏覽器。 隱身模式可確保 Chrome 以干凈的狀態運行。 例如，如果您安裝了很多擴展，這些擴展可能會在您的性能測量中產生干擾。

在您的隱身窗口中加載以下頁面。 這是您要分析的演示。 該頁面顯示了一堆上下移動的藍色小方塊。

https://googlechrome.github.io/devtools-samples/jank/

Simulate a mobile CPU

移動設備的 CPU 能力遠低于臺式機和筆記本電腦。 每當您分析頁面時，請使用 CPU 節流來模擬您的頁面在移動設備上的表現。

下列選項，CPU 4x slowdown, 模擬出運算速度只有當前 1/4 的 CPU：

Set up the demo

很難為所有讀者創建一個始終如一的運行時性能演示。 因此 Google 準備了一個允許自定義屏幕上出現元素數量的 web 應用，以確保您的體驗與您在本教程中看到的屏幕截圖和描述相對一致，而不管您的計算機的硬件配置如何。

(1) 繼續單擊 Add 10，直到藍色方塊的移動速度明顯比以前慢。 在高端機器上，可能需要大約 20 次點擊。

(2) 單擊優化。 藍色方塊應該移動得更快更平穩。

如果您沒有看到優化和未優化版本之間的明顯差異，請嘗試多次單擊“減去 10”并重試。 如果添加太多藍色方塊，只會使 CPU 使用率最大化，并且不會看到兩個版本的結果有很大差異。

Record runtime performance

當您運行頁面的優化版本時，藍色方塊移動得更快。 這是為什么？ 兩個版本都應該在相同的時間內將每個方格移動相同的空間。 在性能面板中進行錄制，了解如何檢測未優化版本中的性能瓶頸。

點擊 Performance 面板的 Record 圖標，開始錄制：

等幾秒鐘后，點擊 Stop:

下面介紹如何解讀 Performances 面板生成的統計數據。

Analyze frames per second

衡量任何動畫性能的主要指標是每秒幀數 (FPS)。當動畫以 60 FPS 運行時，意味著較好的用戶體驗。

查看 FPS 圖表。 每當您看到 FPS 上方的紅色條時，就意味著幀率下降得太低，可能會損害用戶體驗。 一般來說，綠色條越高，FPS 越高。

如下圖所示，我開啟了 recording，然后重復點擊 Add 10，在此過程中，能看到代表 FPS 低于 60 的紅線逐漸升高，然后在 CPU 欄，代表 Rendering 的紫色圖例越來越多。

將鼠標懸停在 FPS、CPU 或 NET 圖表上。 DevTools 顯示了當時頁面的屏幕截圖。 左右移動鼠標可重播錄音。 這稱為擦洗(scrubbing)，它對于手動分析動畫的進程很有用。

看這個 frames 欄：

在框架部分，將鼠標懸停在其中一個綠色方塊上。 DevTools 會向您顯示該特定幀的 FPS。 每幀可能遠低于 60 FPS 的目標。

Bonus: Open the FPS meter

我們還可以使用 FPS meter 觀測一個網頁實時的 FPS 數據。

快捷鍵：Control+Shift+P 選擇 show rendering：

在渲染選項卡中，啟用 FPS Meter。即下圖這個 checkbox：

視口的右上角會出現一個新的疊加層。能顯示實時的 FPS 數據：

我們在 summary 標簽頁里看到，該 web 應用的瓶頸在 rendering：

展開 main 部分。 DevTools 會向您顯示主線程上隨時間變化的活動火焰圖。 x 軸表示隨時間的記錄。 每個條形代表一個事件。

更寬的條形意味著該事件花費的時間更長。 y 軸代表調用堆棧。 當您看到事件堆疊在一起時，這意味著較高的事件導致較低的事件。

recording 中有很多數據。 通過單擊、按住并將鼠標拖動到“概覽”（包括 FPS、CPU 和 NET 圖表的部分）上，放大單個動畫幀觸發事件。 主要部分和摘要選項卡僅顯示所選 recording 部分的信息。

請注意 Animation Frame Fired 事件右上角的紅色三角形。 每當您看到紅色三角形時，即表示可能存在與此事件相關的問題的警告。

每當執行 requestAnimationFrame() 回調時，就會發生 Animation Frame Fired 事件。

單擊動畫幀觸發事件。 “摘要”選項卡現在顯示有關該事件的信息。 注意揭示鏈接。 單擊它會導致 DevTools 突出顯示啟動 Animation Frame Fired 事件的事件。 另請注意 app.js:94 鏈接。 單擊它會將您跳轉到源代碼中的相關行。

app.update = function (timestamp) {for (var i = 0; i < app.count; i++) {var m = movers[i];if (!app.optimize) {var pos = m.classList.contains('down') ?m.offsetTop + distance : m.offsetTop - distance;if (pos < 0) pos = 0;if (pos > maxHeight) pos = maxHeight;m.style.top = pos + 'px';if (m.offsetTop === 0) {m.classList.remove('up');m.classList.add('down');}if (m.offsetTop === maxHeight) {m.classList.remove('down');m.classList.add('up');}} else {var pos = parseInt(m.style.top.slice(0, m.style.top.indexOf('px')));m.classList.contains('down') ? pos += distance : pos -= distance;if (pos < 0) pos = 0;if (pos > maxHeight) pos = maxHeight;m.style.top = pos + 'px';if (pos === 0) {m.classList.remove('up');m.classList.add('down');}if (pos === maxHeight) {m.classList.remove('down');m.classList.add('up');}}}frame = window.requestAnimationFrame(app.update);}

使用鍵盤上下箭頭切換事件的顯示：

在 app.update 事件下，有一堆紫色事件。 如果它們更寬，看起來好像每個上面都有一個紅色三角形。 現在單擊紫色布局事件之一。 DevTools 在摘要選項卡中提供了有關事件的更多信息。 事實上，有一個關于強制回流的警告（布局的另一種說法）。

先選中 app.update, 然后按鍵盤下箭頭，再左右移動，找到這些 forced reflow 的代碼，同樣可以點擊超鏈接看到引起回流的準確代碼行數：

比如第 71 行的 m.offsetTop 引起回流：

這段代碼的問題在于，在每個動畫幀中，它會更改每個方塊的樣式，然后查詢每個方塊在頁面上的位置。 因為樣式改變了，瀏覽器不知道每個方塊的位置是否改變，所以它必須重新布局方塊以計算它的位置。 請參閱避免強制同步布局以了解更多信息。

更多Jerry的原創文章，盡在：“汪子熙”:

總結

以上是生活随笔為你收集整理的Chrome 开发者工具 performance 标签页的用法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。