Chrome 102 版會在開發人員工具中加入新的實驗性面板「Performance Insights」。在這篇文章中，除了探討 Google 開發新專題課程的原因，也要討論我們面臨的技術挑戰，以及我們一路走來的決策。
為什麼要製作其他面板？
(如果您還沒看過我們分享的影片，說明建立「成效深入分析」面板的原因，以及如何善用這項工具取得可做為行動依據的洞察資料。)
如要集中查看網站所有資料，現有效能面板是非常實用的資源，但我們認為這個面板可能會有點繁瑣。如果你不是績效專家，就很難確切知道需要尋找哪些資料，以及影片中的哪些部分與自己有關。
進入「Insights」面板後，您還是可以查看追蹤記錄時間軸並檢查資料，同時取得一份實用清單，輕鬆瞭解開發人員工具應如何成為最值得深入探究的「深入分析」。深入分析將找出導致轉譯封鎖要求、版面配置調整和較長工作等問題，這些問題可能會對網站網頁載入效能造成負面影響，特別是網站的Core Web Vitals (CWV) 分數。除了找出問題外，Performance Insights 還會提供可行的建議，協助你提高 CWV 分數，並提供其他資源和說明文件的連結。
這個面板仍在實驗階段，歡迎提供意見！如果您遇到任何錯誤，或是提出功能要求，都可以對網站效能有所幫助，請聯絡我們。
效能洞察資料的建構方式
如同開發人員工具的其他部分，我們在 TypeScript 中建構了效能深入分析，並使用以 lit-html 支援的網頁元件建構使用者介面。「效能深入分析」的差異在於主要 UI 介面是 HTML canvas 元素，時間軸則繪製在這個畫布上。管理畫布時，可說是件繁瑣的複雜程序：不僅是要在正確位置繪製正確的詳細資料，還要管理滑鼠事件 (例如使用者在畫布上按一下畫布的哪個位置？他們是否點選了我們繪製的活動？)
在單一畫布上加入多首曲目
我們想要顯示特定網站的多個「歷程」，每個軌跡都代表不同的資料類別。舉例來說，「深入分析」面板預設會顯示三個測試群組：
我們會持續將功能介紹在面板上，未來也將陸續推出更多曲目。
我們一開始的想法是，為每個軌道算繪自己的 <canvas>，因此主要檢視畫面會成為多個垂直堆疊的畫布元素。這樣會簡化軌道的算繪作業，因為每個軌跡都可獨立轉譯，並不會在邊界外顯示音軌造成的危險，不過這種做法有兩個重大問題：
canvas 元素對 (重新) 算繪的成本較高；如果有多個畫布，即使畫布較大，也會比使用多個畫布的費用更高。轉譯橫跨多個軌道的所有疊加層 (例如標示 FCP 時間等事件的垂直線) 會變得很複雜：我們必須算繪為多個畫布，並確保所有畫面都能一同轉譯且正確對齊。
針對整個使用者介面使用一個 canvas，我們就必須瞭解如何確保每個軌跡都能以正確的座標顯示，而不會溢出至其他軌跡。舉例來說，如果特定的曲目高度為 100px，我們就無法允許顯示高 120px 的曲目，並藏於下方的軌道中。如要解決這個問題，可以使用 clip。在呈現每個歷程之前，我們會繪製代表可見軌跡視窗的矩形。這樣可以確保在這些邊界外繪製的任何路徑都會遭到畫布裁剪。
canvasContext.beginPath();
canvasContext.rect(
trackVisibleWindow.x, trackVisibleWindow.y, trackVisibleWindow.width, trackVisibleWindow.height);
canvasContext.clip();
我們也不想讓每個測試群組垂直瞭解其垂直位置：每個軌跡都應該像算繪 (0, 0) 一樣顯示，而我們也採用更高層級的元件 (我們呼叫 TrackManager) 來管理整體軌跡位置。方法是使用 translate，以指定 (x, y) 位置將畫布轉譯。例如：
canvasContext.translate(0, 10); // Translate by 10px in the y direction
canvasContext.rect(0, 0, 10, 10); // draw a rectangle at (0, 0) that’s 10px high and wide
儘管將 rect 程式碼設定 0, 0 為位置，但套用的整體平移將會導致矩形算繪為 0, 10。如此一來，我們就能像在 (0, 0) 算繪地球一樣，讓追蹤管理員在轉譯各音軌時加以轉譯，確保每個音軌都能正確轉譯至前一首。
在螢幕外畫布提供曲目和精彩集錦
畫布顯示作業的費用相對較高，因此，我們希望確保「深入分析」面板會在您使用時顯示流暢度和回應。有時您無法避免必須重新轉譯整個畫布，舉例來說，如果您變更縮放等級，我們就必須重新開始並重新轉譯所有內容。畫布重新算繪的成本特別高，因為您無法只重新轉譯一小部分的畫布，而是必須抹除整個畫布，再重新繪製。這與 DOM 重新轉譯不同之處在於，工具可以計算需要的最少工作，且不會移除所有項目並重新啟動。
我們特別強調了視覺問題的部分。您只要將滑鼠遊標移到窗格中的指標上，系統就會在時間軸上醒目顯示這些指標；同樣地，如果您將滑鼠遊標懸停在特定事件的深入分析上，系統就會在該事件周圍畫一個藍色邊框。
這項功能最初的實作方式為偵測滑鼠遊標在會觸發醒目顯示的元素上，然後直接在主畫布上繪製醒目顯示效果。這時我們必須移除醒目顯示的部分，也就是重新繪製所有內容！我們無法只重新繪製亮部區域 (而非進行大型建築變更)，而是重新繪製整個畫布，只是因為我們想移除一個項目周圍的藍色邊框，藉此體會過度勞累。如果將滑鼠快速移動至不同項目上，系統會快速接續觸發多個醒目顯示動作，看起來會不停歇。
為修正這個問題，我們將 UI 分割為兩個「畫面外」畫布：顯示軌跡的「主要」畫布，以及繪製高亮度的「醒目顯示」畫布。接著，我們會將這些畫布複製到螢幕上向使用者顯示的單張畫布上進行算繪。我們可以在畫布環境中使用 drawImage 方法，它可以使用另一個畫布做為來源。
也就是說，移除螢光筆並不會導致主要畫布被重新繪製，因此我們可以清除螢幕上的畫布，再將主畫布複製到可見畫布上。複製畫布十分便宜，所畫的成本也很高昂。因此，只要將亮點移到另一個畫布上，就能避免在開啟或關閉醒目顯示功能時降低成本。
全面測試追蹤記錄剖析
從頭開始建構新功能的其中一個好處，就是可以反映出之前的技術選擇並加以改進。我們想要改善的其中一件事，就是明確將程式碼分割為兩個且幾乎完全不同的部分：
剖析追蹤檔並提取必要資料。算繪一組軌跡。
只要將剖析 (第 1 部分) 與 UI 作業分開 (第 2 部分)，我們就能建構出可靠的剖析系統；每個追蹤記錄都會透過一系列的處理常式執行，且每個處理常式負責不同的考量：LayoutShiftHandler 會計算版面配置位移所需的所有資訊，NetworkRequestsHandler 只會計算提取網路要求。在這個明確剖析步驟中，我們有分別負責追蹤記錄不同部分的不同處理常式，也會帶來許多好處：追蹤記錄剖析作業可能會變得非常複雜，而且有助於一次專注於一個疑慮。
另外，我們也在 DevTools 中錄製錄製內容，然後儲存並載入測試套件一併載入，藉此全面測試追蹤記錄剖析結果。這是因為我們可以使用真實的追蹤記錄進行測試，並且不會建立可能會過時的大量虛假追蹤資料。
畫布 UI 螢幕截圖測試
延續測試主題，我們通常會將前端元件算繪到瀏覽器，並確保這些元件運作正常；我們可以分派點擊事件以觸發更新，同時斷言元件產生的 DOM 是正確的。我們覺得這種方法很有效，但在我們考慮到畫布上時就會下降，也就是無法檢查畫布及確認其中繪製的內容！因此，我們一般的轉譯方法和查詢方法並不適當。
為了讓我們能參與部分測試，我們採用了螢幕截圖測試。每次測試都會觸發一個畫布，呈現要測試的音軌，然後擷取畫布元素的螢幕截圖。系統會將這張螢幕截圖儲存在程式碼集中，未來測試執行時會將儲存的螢幕截圖與產生的螢幕截圖進行比較。如果螢幕截圖不同，測試就會失敗。我們也會提供用來執行測試的旗標，當我們刻意變更算繪畫面，且需要更新測試時，會強制更新螢幕截圖。
螢幕截圖測試並不是完全完美，而且有點令人困擾；您只能測試整個元件是否如預期正常轉譯，而不是更具體的斷言。而且我們一開始會出錯，確保每個元件 (HTML 或畫布) 都能正確轉譯。這會大幅降低測試套件的執行速度，並導致以下問題導致使用者介面微調 (例如細微顏色的改變，或在項目之間增加一些邊界) 造成多張螢幕截圖失敗且必須更新。現在，我們縮減了螢幕截圖的使用範圍，僅將螢幕截圖用於畫布型元件，而到目前為止，這個餘額都相當滿意。
結論
建構新版「效能深入分析」面板是為團隊帶來精彩有趣的教育體驗。我們已經學到很多關於追蹤檔、使用畫布等功能的知識。希望您會喜歡這個新版面板，也期待收到您的寶貴意見。
如要進一步瞭解「成效深入分析」面板，請參閱「成效洞察：取得可做為行動依據的網站成效的可做為行動依據的洞察資料」。
下載預覽管道
考慮使用 Chrome Canary 版、開發人員版或 Beta 版做為預設開發瀏覽器。這些預覽管道可讓您存取開發人員工具的最新功能、測試最先進的網路平台 API，並在使用者使用之前就在網站上發現問題！
與 Chrome 開發人員工具團隊聯絡
使用下列選項，討論文章的新功能和異動，以及其他與開發人員工具相關的事項。
- 請透過 crbug.com 提交建議或意見回饋。
- 如要回報開發人員工具的問題，請在開發人員工具中依序點選「更多選項」圖示
>「說明」 >「回報開發人員工具的問題」。 - 在 @ChromeDevTools 張貼推文。
- 歡迎對開發人員工具的 YouTube 影片或開發人員工具秘訣 (YouTube 影片) 提供意見。