摘要：原文地址開始在本教程中，你將學會如何使用性能分析工具分析頁面上的性能瓶頸。其中包含了捕獲性能指標相關的設置。參考分析優化版的性能使用剛剛學習的工作流和工具，單擊演示中的優化以啟用優化的代碼，進行另一次性能記錄，然后分析結果。

原文地址：https://developers.google.com...

在本教程中，你將學會如何使用性能分析工具分析頁面上的性能瓶頸。

在隱身模式下打開Google Chrome。隱身模式確保Chrome在干凈的狀態下運行。例如，如果你安裝了很多擴展，這些擴展可能會影響到性能分析的結果。

在隱身窗口中加載以下頁面。這是本教程的Demo，頁面顯示了一堆上下移動的藍色小方塊。

https://googlechrome.github.i...

接著按 F12 打開 DevTools。

圖1: Demo 在左側，DevTools在右側。

注意：為了保證更好的閱讀體驗，在后續的截圖中，DelTools分到多帶帶的窗口顯示。

移動設備的CPU算力比臺式機和筆記本電腦小得多。無論何時評測頁面，都可以使用CPU調節來模擬頁面在移動設備上的表現。

在DevTools中，單擊 Performance 選項卡。

確保選中了 Screenshots 。

單擊 Capture Settings（設置按鈕）。其中包含了捕獲性能指標相關的設置。

對于 CPU選項，選擇 2x slowdown。DevTools會進行 CPU 節流，使其比平時慢2倍。

圖2: CPU 節流，藍色框區域

注意：在測試其他頁面時，如果要確保它們在低端移動設備上工作良好，請將CPU節流設置為減速20倍。這個演示不能很好地使用20倍的減速，所以它只使用2倍的減速作為教學目的。

很難為本網站的所有讀者創建一致的運行時性能演示。本節允許你自定義演示，以確保你的體驗與你在本教程中看到的屏幕截圖和描述相對一致，而不管你的特定設置如何。

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

單擊 Optimize，藍色方塊應該移動得更快更流暢。

單擊 Un-Optimize，藍色方塊應該移動得更慢且更加卡頓

注意：如果你看不到優化版本和未優化版本之間的明顯差異，請嘗試單擊 Subtract 10 幾次，然后再試一次。如果你添加太多的藍色方塊，相當于把CPU都幾乎占滿了，就看不到優化和不優化版本的差異。

當你運行優化版本時，藍色方塊移動得更快。為什么？兩個版本都應該在相同的時間內，將每個方塊移動相同的距離。在性能面板中錄制，學習如何檢測未優化版本中的性能瓶頸。

在 DevTools 中，單擊 Record（左上角灰色圓圈）。DevTools 會捕捉頁面運行時的性能指標。

圖3：頁面記錄中

等待幾秒

單擊 Stop，DevTools 停止記錄，分析數據，然后會將分析結果展示在性能面板中。

圖4：分析的結果

哇，這么多的數據。別慌，很快我們就知道具體的含義了。

一旦你拿到了頁面的性能分析數據，你會發現這個頁面的性能到底有多差，并且找到導致頁面性能差的原因。

衡量任何動畫性能的主要指標就是幀率(FPS)。當動畫以60 fps的速度運行時，用戶會很爽。

注意FPS圖表。只要你看到一條紅條，就意味著低幀率，進而影響用戶體驗。通常來說，綠色的柱條越高，代表幀率越高。

圖5：藍框內的FPS圖表

在FPS圖表下方，你可以看到CPU圖表。CPU圖表中的顏色與“性能”面板底部的 Summary 選項卡中的顏色相對應。CPU 圖表充滿顏色意味著CPU在記錄過程中達到了最大負載。每當你看到CPU長時間達到最大負載時，這是進行優化的一個很好的提示。

圖6：藍框內的 CPU 圖表和 Summary（摘要欄）

將鼠標懸停在 FPS、CPU 或 NET 圖表上。DevTools 顯示該頁面在該時間點的屏幕截圖。向左和向右移動鼠標以重放記錄過程。這稱為 scrubbing，它對于手動分析動畫過程很有用。

圖7：查看頁面在2000ms左右時的屏幕截圖

在 Frames 區域中，將鼠標懸停在其中一個綠色方塊上。DevTools 向你顯示該特定幀的 FPS。每幀可能遠遠低于60 FPS。

圖8：鼠標懸停在一幀上

當然，在這個 DEMO 中，很明顯這個頁面的性能不是很好。但是在真實的場景中，我們不一定能一眼分辨出一個頁面的性能好壞，所以使用這些工具來進行測量分析是很方便的。

現在你已經測量并驗證了頁面動畫表現不佳，接下來要回答的問題是：為什么？

注意 Summary 選項卡，在未選擇任何事件時，它呈現了瀏覽器在整個記錄過程中把時間花在哪個部分。可以看到，頁面的大部分時間都花在渲染上。所以現在的目標就是：減少瀏覽器花費在渲染工作上的時間。

圖9：藍框內的 Summary 選項卡

展開 Main 區域，DevTools 向你展示了一段時間內主線程上活動圖。x 軸代表著這段時間內的記錄，每一個 Bar 都代表了一個事件。Bar 越寬，意味著該活動花費的時間更長。y軸表示調用堆棧，當你看到事件堆疊在一起時，這意味著上面的事件導致了下面的事件。

圖10：藍框內的 Main 區域

記錄過程中有很多數據。在 OverView 面板（有 CPU, FPS, NET 圖表的區域）上，用鼠標單擊、按住、拖拽來放大單個 Animation Frame Fired 事件。此時 Main 和 Summary 中展示了選中的區間的相關信息。

圖11：放大單個 Animation Frame Fired 事件

提示：你也可以通過單擊 Main 中的某個事件后，通過鼠標的滾輪或者 W,S,A,D 鍵實現單個事件的縮放。

注意在 Animation Frame Fired 事件右上角的紅三角。只要你看到了紅三角，這個事件就可能造成嚴重的問題。

提示：每當 requestAnimationFrame()  回調調用時, 都會觸發 Animation Frame Fired 事件

單擊某個 Animation Frame Fired 事件, Summary 中會展示與該事件相關的信息. 注意 reveal 鏈接，單擊后，DevTools 會將觸發當前的 Animation Frame Fired 事件的事件高亮出來。同時注意 app.js:94 鏈接，單擊后跳轉到相應的源碼。

圖12： 查看 Animation Frame Fired 事件的詳細信息

提示：選中一個事件之后，用左右方向鍵可以跳轉到上/下一個事件

在 app.update 事件下，有一堆紫色事件。稍微放大，看起來每個都可能有一個紅色的三角形。現在單擊其中一個紫色事件。DevTools 在 Summary 中提供了有關事件的詳細信息。可以看到，有一個關于強制回流(forced reflows)的警告(也就是 Layout 的另一種說法)。

在 Summary 中，單擊 Layout Forced 下的 app.js:70 鏈接，DevTools 會跳轉到引發強制回流的源代碼。

圖13：導致強制回流的源代碼

注意：這行代碼的問題在于：修改了藍塊樣式之后，立刻讀取藍塊 offsetTop 值。此時樣式變更，而offsetTop 值是上一幀的值，瀏覽器為了保證讀取 offsetTop 值的準確性，會先處理樣式變更，然后重新布局以計算準確的 offsetTop 值，而重新布局（回流）的性能開銷是很大的。參考：Avoid_forced_synchronous_layouts

使用剛剛學習的工作流和工具，單擊演示中的優化以啟用優化的代碼，進行另一次性能記錄，然后分析結果。從改進的幀率到 Main 中的活動圖表中事件的減少，你可以看到應用程序的優化版本做的工作少得多，從而帶來更好的性能。

app.update = function (timestamp) {
    for (var i = 0; i < app.count; i++) {
      var m = movers[i];
      if (!app.optimize) { // 1.普通版本
        var pos = m.classList.contains("down") ?
            m.offsetTop + distance : m.offsetTop - distance; // 讀取offsetTop, 變更樣式
        if (pos < 0) pos = 0;
        if (pos > maxHeight) pos = maxHeight;
        m.style.top = pos + "px";
        if (m.offsetTop === 0) { // 樣式變更后讀取 offsetTop，導致回流
          m.classList.remove("up");
          m.classList.add("down");
        }
        if (m.offsetTop === maxHeight) { // 樣式變更后讀取 offsetTop，導致回流
          m.classList.remove("down");
          m.classList.add("up");
        }
      } else { // 2.優化版本
        var pos = parseInt(m.style.top.slice(0, m.style.top.indexOf("px")));
        m.classList.contains("down") ? pos += distance : pos -= distance; // 通過讀取top，來獲取原來藍塊的位置，避免讀取 offsetTop 
        if (pos < 0) pos = 0;
        if (pos > maxHeight) pos = maxHeight;
        m.style.top = pos + "px";
        if (pos === 0) { // 樣式變更后用從樣式 top 中讀取到的位置信息進行判斷，避免讀取 offsetTop
          m.classList.remove("up");
          m.classList.add("down");
        }
        if (pos === maxHeight) {
          m.classList.remove("down");
          m.classList.add("up");
        }
      }
    }
    frame = window.requestAnimationFrame(app.update);
  }

注意：優化版本的代碼雖然不會觸發回流(Layout)，但依然會觸發重繪(Paint)。一個更好的解決方案是使用只會觸發合成(Composite)的屬性，例如： transform 和 opacity。
參考： Use transform and opacity changes for animations

了解性能的基礎是軌道模型(The RAIL model)。這個模型告訴你對你的用戶來說最重要的性能指標。有關詳細信息，請參見 Measure Performance With The RAIL Model 。

為了讓性能面板更舒適，熟能生巧。嘗試分析自己的頁面并分析結果。如果你對結果有任何疑問，去Stack Overflow 提出關于 google-chrome-devtools 的問題。如果可能，包括可復制頁面的截圖或鏈接。

要真正掌握運行時性能，你必須了解瀏覽器如何將HTML、CSS和JS轉換為屏幕上的像，可以參考： Rendering Performance Overview. 這篇文章則更加深入：The Anatomy Of A Frame

最后，有許多方法可以提高運行時性能。本教程將重點放在一個特定的動畫瓶頸上，讓你通過性能面板進行重點介紹，但這只是你可能遇到的眾多瓶頸之一。如何提升頁面運行時的性能還可以參考以下關于渲染性能的文章：

Optimizing JS Execution

Reduce The Scope And Complexity Of Style Calculations

Avoid Large, Complex Layouts And Layout Thrashing

Simplify Paint Complexity And Reduce Paint Areas

Stick To Compositor-Only Properties And Manage Layer Count

Debounce Your Input Handlers