在 Chrome 102 中，您會發現開發人員工具中新增了實驗面板「效能深入分析」。在這篇文章中，我們不僅會說明為何要開發新面板，還會討論我們面臨的技術挑戰，以及過程中做出的決策。
為何要建構另一個面板？
(如果還沒看過，我們已發布影片，說明為何要建構「成效洞察」面板，以及如何運用這項工具，取得網站成效的實用洞察資料)。
現有的成效面板是查看網站所有資料的絕佳資源，但我們認為這項工具可能有點複雜。如果您不是效能專家，很難確切知道要尋找什麼，以及錄製內容的哪些部分與效能相關。
進入「洞察面板」後，您仍可查看追蹤記錄的時間軸並檢查資料，但也會取得一份實用清單，列出開發人員工具認為值得深入探究的主要「洞察」。洞察功能會找出問題，例如導致轉譯遭到封鎖的要求、版面配置位移和長時間工作等，這些問題都會對網站的網頁載入效能造成負面影響，尤其是網站的核心網頁指標 (CWV) 分數。除了標記問題，效能洞察還會提供實用的建議，協助您改善核心網頁指標分數，並提供其他資源和文件的連結。
這個面板目前為實驗功能，歡迎提供意見！如果您發現任何錯誤，或有任何功能要求，認為有助於提升網站效能，請告訴我們。
我們如何建構成效洞察
與其他開發人員工具一樣，我們使用 TypeScript 建構了「效能深入分析」，並使用 網頁元件 (由 lit-html 提供支援) 建構使用者介面。「成效洞察」的主要 UI 介面是 HTML canvas 元素，時間軸會繪製在這個畫布上，這就是兩者的差異。管理這個畫布相當複雜，不僅要在正確位置繪製正確的詳細資料，還要管理滑鼠事件 (例如：使用者點選畫布的位置？他們是否點選我們繪製的事件？)，並確保我們有效重新算繪畫布。
在單一畫布上顯示多個軌道
針對特定網站，我們想要算繪多個「軌跡」，每個軌跡代表不同類別的資料。舉例來說，洞察面板預設會顯示三條軌跡：
隨著我們持續在面板上推出新功能，預計會有更多曲目加入。
我們最初的想法是讓每個軌道自行算繪 <canvas>，這樣主畫面就會變成垂直堆疊的多個畫布元素。這樣做可簡化軌道層級的算繪作業，因為每個軌道都可以獨立算繪，且不會有軌道在界線外算繪的風險，但很遺憾，這種做法有兩個主要問題：
canvas 元素 (重新) 算繪的成本很高；即使畫布較大，多個畫布的成本仍高於一個畫布。
如果要在多個軌道上算繪任何疊加層 (例如標記 FCP 時間等事件的垂直線)，就會變得相當複雜：我們必須在多個畫布上算繪，並確保這些畫布一起算繪，且對齊方式正確無誤。
為整個 UI 使用單一 canvas，表示我們必須找出如何確保每個軌道都以正確的座標算繪，且不會溢位到其他軌道。舉例來說，如果特定軌道的高度為 100 像素，我們就不能允許系統算繪高度為 120 像素的內容，並讓該內容溢出到下方的軌道。如要解決這個問題，可以使用 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 部分) 分開，有助於我們建構穩固的剖析系統；每項追蹤記錄都會經過一系列 Handlers，負責處理不同問題：LayoutShiftHandler 會計算版面配置位移所需的所有資訊，而 NetworkRequestsHandler 則專門負責擷取網路要求。我們明確進行剖析步驟，由不同的處理常式負責處理追蹤記錄的不同部分，這也很有幫助：追蹤記錄剖析可能非常複雜，一次專注於一個問題有助於簡化作業。
此外，我們還能透過開發人員工具錄製追蹤記錄、儲存記錄，然後將記錄載入測試套件，全面測試追蹤記錄剖析功能。這很棒，因為我們可以透過實際追蹤記錄進行測試，不必建立大量可能過時的虛假追蹤記錄資料。
畫布 UI 的螢幕截圖測試
繼續談到測試，我們通常會將前端元件算繪到瀏覽器中，並確保元件運作正常，藉此測試元件；我們可以傳送點擊事件來觸發更新，並確認元件產生的 DOM 正確無誤。這種方法很適合我們，但如果考慮要將內容算繪到畫布上，就會遇到問題，因為無法檢查畫布並判斷繪製的內容！因此，我們通常採用的方法 (先算繪再查詢) 並不適用。
為了進行部分測試，我們採用了螢幕截圖測試。每個測試都會啟動畫布、算繪要測試的音軌，然後擷取畫布元素的螢幕截圖。這張螢幕截圖隨後會儲存在程式碼庫中，日後執行測試時，系統會將儲存的螢幕截圖與產生的螢幕截圖進行比較。如果螢幕截圖不同，測試就會失敗。我們也會提供標記來執行測試，並在刻意變更算繪內容時強制更新螢幕截圖，以便更新測試。
螢幕截圖測試並不完美，而且有點粗略；您只能測試整個元件是否如預期轉譯，而無法進行更具體的斷言。一開始，我們為了確保每個元件 (HTML 或畫布) 都能正確轉譯，而過度使用這類測試。這大幅減緩了測試套件的速度，而且導致一些問題，例如微小且幾乎無關的使用者介面調整 (例如細微的顏色變化，或是在項目之間新增一些邊界)，會導致多張螢幕截圖失敗，需要更新。我們現在已減少使用螢幕截圖，只將其用於以畫布為基礎的元件，目前為止這種平衡方式對我們來說很有效。
結論
對團隊來說，建構新的「成效洞察」面板是一項非常有趣且具教育意義的體驗。我們已學到許多有關追蹤記錄檔、使用畫布等方面的知識。希望您喜歡新面板，並期待收到您的意見回饋。
如要進一步瞭解「效能深入分析」面板，請參閱「效能深入分析：取得網站效能的實用洞察資料」。
下載預覽版頻道
建議使用 Chrome Canary、開發人員版或 Beta 版做為預設開發瀏覽器。透過這些搶先體驗管道，您可以存取最新的開發人員工具功能、測試最先進的網頁平台 API，並在使用者發現問題前找出網站上的問題！
與 Chrome 開發人員工具團隊聯絡
如要討論開發人員工具的新功能、更新或其他相關事項，請使用下列選項。
- 如要提供意見回饋或提出功能要求，請前往 crbug.com。
- 如要回報開發人員工具的問題，請依序點選開發人員工具中的 「更多選項」 >「說明」 >「回報開發人員工具的問題」。
- 在 Twitter 訊息中標記 @ChromeDevTools。
- 在「開發人員工具最新消息」或「開發人員工具提示」YouTube 影片中留言。