執行階段效能是指網頁在運作期間 (而非載入) 時的成效。本教學課程說明如何使用 Chrome 開發人員工具效能面板分析執行階段效能。就 RAIL 模型而言，您在本教學課程中學到的技巧，將有助於分析網頁的「回應」、「動畫」和「閒置」階段。
立即開始
在此教學課程中，您會在線上頁面開啟 DevTools，並使用「效能」面板在頁面上尋找效能瓶頸。
- 以無痕模式開啟 Google Chrome。無痕模式可確保 Chrome 以乾淨的狀態執行，舉例來說，如果您安裝了許多擴充功能，這些擴充功能可能會在效能評估中產生雜訊。
在無痕式視窗中載入以下網頁。這是您要剖析的示範畫面。頁面上顯示有許多上下移動的藍色小方塊。
https://googlechrome.github.io/devtools-samples/jank/按下 Command + Option + I 鍵 (Mac) 或 Control + Shift + I 鍵 (Windows、Linux) 開啟開發人員工具。
圖 1：左側的示範畫面，右側是開發人員工具
模擬行動裝置 CPU
行動裝置的 CPU 效能遠低於桌上型電腦和筆記型電腦。每當您剖析頁面時，請使用 CPU 節流功能來模擬網頁在行動裝置上的效能。
- 在開發人員工具中，按一下「效能」分頁標籤。
- 確認已啟用「螢幕截圖」核取方塊。
- 按一下「Capture Settings」圖示
。開發人員工具會顯示與擷取成效指標的方式相關的設定。 在「CPU」部分，選取「2x 減速」。開發人員工具會調節 CPU，將時間比平時慢 2 倍。
圖 2：CPU 節流，藍色輪廓
設定示範
要建立對這個網站所有讀者一致的執行階段效能示範並不容易。本節可讓您自訂示範，無論特定設定為何，都能確保使用體驗與本教學課程中呈現的螢幕截圖和說明相對一致。
- 繼續點選「新增 10」，直到藍色方塊大幅移動速度明顯變慢為止。在高階電腦上，可能需要大約 20 次點擊。
按一下「最佳化」。藍色方塊應該可以更快、更順暢。
按一下「取消最佳化」。藍色方塊的移動速度較慢，卡頓也較多。
記錄執行階段效能
執行最佳化的網頁版本後，藍色方塊的移動速度更快。Why is that? 兩個版本應該在相同時間內移動每個正方形，大小相同。請在「Performance」(效能) 面板中錄製會議，瞭解如何偵測未最佳化版本中的效能瓶頸。
在開發人員工具中，按一下「Record」
。開發人員工具會在頁面執行時擷取成效指標。
圖 3：剖析頁面
稍等幾秒鐘。
按一下「停止」。開發人員工具會停止記錄並處理資料，然後在「效能」面板中顯示結果。
圖 4：剖析資料的結果
哇，這個數字太驚人了。別擔心，很快會更好。
分析結果
系統擷取網頁效能後，您就可以評估網頁效能的差異，並找出原因。
分析每秒影格數
測量任何動畫效能的主要指標是每秒影格數 (FPS)。動畫以每秒 60 個影格數執行時，使用者會很開心。
查看「FPS」圖表。每當「FPS」上方顯示紅色長條，就表示影格速率過低，進而可能對使用者體驗造成負面影響。一般來說，綠色長條越高， FPS 就越高。
圖 5： FPS 圖表，藍色輪廓
「FPS」圖表下方有「CPU」圖表。「CPU」圖表中的顏色會對應至「Performance」面板底部「Summary」分頁中的顏色。如果 CPU 圖表填滿了顏色，代表 CPU 在記錄期間達到了最大程度。每當您發現 CPU 長時間超過最大限度時，就表示該方法就是設法減少工作量的方法。
圖 6：「CPU 圖表」和「摘要」分頁 (藍色外框)
將滑鼠遊標懸停在「FPS」、「CPU」或「NET」圖表上。開發人員工具會顯示該時間點的網頁螢幕截圖將滑鼠向左或向右移動即可重播錄製內容。這稱為拖曳作業，適合用來手動分析動畫的進度。
圖 7：查看影片 2000 毫秒標記左右處的頁面螢幕截圖
在「Frames」部分中，將滑鼠遊標懸停在其中一個綠色正方形上。開發人員工具會顯示特定影格的每秒影格數每個影格都可能低於 60 FPS 的目標。
圖 8：將滑鼠遊標懸停在框架
當然，在這個示範下，很容易看出頁面成效不佳。但在現實生活中，光是這樣可能不夠清楚，因此具備所有進行測量的工具就能派上用場。
額外步驟：開啟 FPS 計量器
另一個實用的工具是 FPS 計量器，可在頁面執行時提供 FPS 的即時預估值。
- 按下 Command + Shift + P 鍵 (Mac) 或 Control + Shift + P 鍵 (Windows 和 Linux)，開啟「指令選單」。
- 在「指令」選單中輸入
Rendering，然後選取「Show Rendering」。 在「Rendering」分頁中，啟用「FPS Meter」。新的疊加層會顯示在可視區域的右上方。
圖 9：FPS 計
停用「FPS Meter」，然後按下 Escape 鍵即可關閉「Rendering」分頁。在本教學課程中不會用到這個項目。
找出瓶頸
現在您已測量並驗證動畫的成效不佳，接下來要回答的問題是：為什麼？
注意摘要分頁。如果沒有選取事件，這個分頁會顯示活動詳細資料。 頁面轉譯時間大部分是花時間。由於效能是處理較少工作的藝術，因此目標是減少轉譯工作所需的時間。
圖 10：「摘要」分頁 (藍色外框)
展開「Main」(主要) 部分。開發人員工具會顯示主執行緒上活動的火焰圖。X 軸代表一段時間內的記錄。每個長條都代表一個事件。長條越大，表示事件所需時間較長。Y 軸代表呼叫堆疊。如果您發現事件彼此堆疊，就代表事件上限是導致事件發生順序較低的事件。
圖 11：「主要」部分，以藍色外框
錄音檔中有大量資料，在「Overview」(包含「FPS」、「CPU」、「NET」圖表的專區中) 上按一下、按住及拖曳滑鼠，即可放大單一「Animation Frame Fired」事件。「Main」區段和「Summary」分頁只會顯示記錄所選部分的資訊。
圖 12：放大已觸發的單一動畫頁框事件
請注意「已觸發動畫框架」事件右上方的紅色三角形。只要看到紅色三角形，就表示可能與此事件有關的問題。
按一下「已觸發動畫頁框」事件。「Summary」分頁現在會顯示該事件的相關資訊。記下「顯示」連結。只要按一下該事件，開發人員工具就會醒目顯示啟動「Animation Frame Fired」事件的事件。另請注意 app.js:94 連結。只要按一下該選項，您就會前往原始碼中的相關行。
圖 13：進一步瞭解動畫頁框觸發事件
app.update 事件底下有許多紫色的事件。如果寬度較寬，看起來就好像每個項目上都有紅色三角形。立即按一下其中一個紫色的「Layout」事件。開發人員工具的「摘要」分頁會提供事件的詳細資訊。當然，還有強制自動重排 (版面配置的另一個字詞) 的警告。
在「Summary」分頁中，按一下「Layout Forced」下方的「app.js:70」連結。開發人員工具會帶你前往強製版面配置的程式碼行。
圖 13：導致強製版面配置的程式碼行
大功告成！這需要用到很多，但現在在基本工作流程中已奠定了穩固基礎，可用於分析執行階段效能。做得好！
額外步驟：分析最佳化的版本
使用您剛學到的工作流程和工具，按一下示範上的「最佳化工具」來啟用最佳化程式碼、再次錄製效能記錄，然後分析結果。從改善的影格速率，到「Main」火焰圖 (火焰圖) 中的事件減少幅度，您可以發現經過最佳化的應用程式處理的工作少很多，因此能夠獲得更好的效能。
後續步驟
瞭解效能的基礎是 RAIL 模型。這個模型會教導使用者最重視的成效指標。詳情請參閱「使用 RAIL 模型評估效能」。
想要更加熟悉「效能」面板，不斷練習是完美的。請試著剖析您自己的網頁並分析結果。如果您對結果有任何疑問，請開啟標有 google-chrome-devtools 的 Stack Overflow 問題。請盡可能提供螢幕截圖或可重現頁面的連結。
要成為執行階段效能的專家，你必須瞭解瀏覽器如何將 HTML、CSS 和 JS 轉譯為螢幕上的像素。建議您先參閱「轉譯效能總覽」。《The Anatomy Of A Frame》深入探討更多細節。
最後，改善執行階段效能的方法很多，本教學課程著重於一項特定動畫瓶頸，以協助您使用「Performance」面板進行重點導覽，但這只是可能會遇到的瓶頸之一。「算繪效能」系列的其餘部分有許多實用訣竅，幫助您改善執行階段效能的各個面向，例如：