我們建構成效深入分析的方式和原因

Jack Franklin

在 Chrome 102 中，開發人員工具中會顯示全新的實驗性面板 Performance Insights。在本篇文章中，我們將討論為何我們一直在開發新的資訊面板，以及我們面臨的技術挑戰和做出的決策。

ALT_TEXT_HERE

為何要建立另一個面板？

(如果您尚未觀看，我們發布了一段影片，說明為何要建立「成效深入分析」面板，以及如何透過該面板取得可採取行動的網站成效洞察資料)。

如果您想集中查看網站的所有資料，現有的成效面板是很實用的資源，但我們認為這可能讓人不知從何著手。如果你不是效能專家，就很難確切知道要尋找什麼，以及錄音檔的哪些部分與效能相關。

進入「深入分析」面板後，您仍可查看追蹤記錄的時間軸並檢查資料，但也會看到 DevTools 認為值得深入探討的主要「深入分析」項目清單。洞察功能會找出各種問題，例如轉譯阻擋要求、版面配置變更和長時間工作，這些問題都可能對網站的網頁載入效能造成負面影響，特別是網站的 Core Web Vitals (CWV) 分數。除了標示問題，成效深入分析也會提供可行的建議，協助您改善 CWV 分數，並提供其他資源和說明文件的連結。

面板中的意見回饋連結

這個面板仍在實驗階段，因此需要你提供寶貴意見！如果您遇到任何錯誤，或有任何有助於改善網站效能的功能要求，請與我們聯絡。

成效深入分析的建立方式

和開發人員工具的其他部分一樣，我們在 TypeScript 中建立了效能深入分析，並使用 lit-html 的網頁元件建立使用者介面。「成效深入分析」的差別在於主要 UI 介面是 HTML canvas 元素，時間軸會顯示在這個畫布上。管理這個畫布的複雜性相當高：不僅要確保在正確的位置繪製正確的細節，還要管理滑鼠事件 (例如：使用者在畫布上點選的位置為何？是否點選了我們繪製的事件？)，並確保有效重新算繪畫布。

單一畫布上的多個軌道

系統在特定網站上要呈現多個「歷程」，每個軌跡都代表不同的資料類別。舉例來說，「洞察」面板預設會顯示三種測試群組：

隨著我們持續在面板中推出更多功能，我們也預期會新增更多曲目。

我們最初的想法是讓每個軌道都算繪自己的 <canvas>，讓主要檢視畫面成為垂直堆疊的多個畫布元素。這麼做可簡化音軌層級的算繪作業，因為每個音軌都能單獨算繪，且不會有音軌算繪超出其邊界的問題，但這種做法有兩個主要問題：

canvas 元素的算繪/重新算繪作業成本較高；即使單一畫布較大，多個畫布的成本仍會更高。在多個軌道上算繪任何疊加層 (例如用來標示 FCP 時間等事件的垂直線) 會變得複雜：我們必須在多個畫布上算繪，並確保所有畫布都算繪在一起且正確對齊。

使用一個 canvas 來處理整個 UI，意味著我們需要找出如何確保每個軌跡都能在正確的座標處算繪，且不會溢位到其他軌跡。舉例來說，如果某個特定音軌的高度為 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 重新轉譯不同，工具可以計算最少的工作，不用移除全部內容再重新開始。

我們在視覺效果方面遇到的問題之一，就是醒目顯示。當您將滑鼠遊標懸停在窗格中的指標時，系統會在時間軸上醒目顯示這些指標；同樣地，如果您將遊標懸停在特定事件的深入分析上，我們也會在事件周圍繪製藍色邊框。

這項功能最初是透過偵測滑鼠在觸發醒目顯示的元素上移動，然後直接在主要畫布上繪製醒目顯示畫面來實作。當我們必須移除醒目顯示時，就會遇到問題：唯一的選項就是重新繪製所有內容！我們無法只重新繪製醒目顯示的區域 (除非要進行重大的架構變更)，但如果只是為了移除某個項目周圍的藍色邊框，重新繪製整個畫布似乎有點過頭。此外，如果快速移動滑鼠游標至不同項目，以便快速觸發多個醒目顯示，也會造成視覺延遲。

為解決這個問題，我們將使用者介面分割成兩個「螢幕外」畫布：將導覽算繪至「主要」畫布，以及用來繪製醒目提示的「醒目顯示」畫布。接著，我們會將這些畫布複製到使用者可在螢幕上看到的單一畫布上進行算繪。我們可以在畫布內容上使用 drawImage 方法，這可使用其他畫布做為來源。

這表示移除醒目顯示不會導致主畫布重新繪製：我們可以清除畫面上的畫布，然後將主畫布複製到可見的畫布上。複製畫布的成本很低，繪製畫面才會耗費大量資源；因此，將醒目顯示移至另一個畫布，就能避免開啟和關閉醒目顯示時的成本。

全面測試追蹤記錄剖析

從頭開始建構新功能的好處之一，就是您可以反思先前做出的技術選擇，並加以改善。我們希望改善的其中一項內容，就是明確將程式碼分成兩個幾乎完全不同的部分：

剖析追蹤記錄檔並提取所需資料。轉譯一組音軌。

將剖析 (第 1 部分) 與 UI 工作區隔開來 (第 2 部分) 讓我們能建構穩固的剖析系統，每個追蹤記錄都會透過一系列負責不同疑慮的處理常式執行：LayoutShiftHandler 計算我們需要在版面配置位移上所需的所有資訊，而 NetworkRequestsHandler 則專門處理提取網路要求。這種明確的剖析步驟能讓我們由不同的處理常式處理追蹤記錄的不同部分，這樣也能帶來許多助益：追蹤剖析可能非常複雜，而且您可以一次專心處理一個疑慮。

我們也在開發人員工具中擷取並儲存記錄，然後載入為測試套件的一部分，藉此全面測試追蹤記錄剖析結果。這麼做很棒，因為我們可以使用實際的追蹤記錄進行測試，而不會累積大量可能過時的假追蹤記錄資料。

畫布 UI 的螢幕截圖測試

回到測試主題，我們通常會將前端元件轉譯至瀏覽器，並確保其行為符合預期，藉此測試前端元件；我們可以發送點擊事件來觸發更新，並斷言元件產生的 DOM 是否正確。這個做法對我們很有效果，但在考慮將畫布算繪到畫布時，這個方式已下降，因此無法檢查畫布並確認畫布繪製的項目！因此，我們通常採用的算繪及查詢方法並不適合。

為了讓測試涵蓋率達到一定程度，我們改用螢幕截圖測試。每個測試都會啟動畫布、算繪要測試的軌跡，然後擷取畫布元素的螢幕截圖。系統會將這個螢幕截圖儲存在程式碼庫中，日後執行測試時，系統會將儲存的螢幕截圖與產生的螢幕截圖進行比較。如果螢幕截圖不同，測試就會失敗。我們也提供標記，可在我們刻意變更算繪作業並需要更新測試時，執行測試並強制更新螢幕截圖。

螢幕截圖測試並非完美無缺，而且有點直白；您只能測試整個元件是否如預期顯示，而非更具體的斷言，而且我們一開始過度使用這些斷言，以確保每個元件 (HTML 或畫布) 都能正確顯示。這會大幅減緩測試套件的速度，並導致以下問題：微小且幾乎無關的 UI 調整 (例如微妙的顏色變更，或在項目間增加一些邊距) 會導致多個螢幕截圖失敗，並需要更新。我們現在已縮減螢幕截圖的使用量，並將其用於純粹以畫布為基礎的元件，而這種平衡方式目前對我們來說運作良好。

結論

全新成效洞察面板一直是團隊都很開心的教學體驗。我們已瞭解許多關於追蹤記錄檔的知識，也學會如何使用畫布等等。希望你喜歡這個新面板，也期待收到你的意見回饋。

如要進一步瞭解「成效深入分析」面板，請參閱「成效深入分析：取得網站成效的可行深入分析資料」一文。

下載預覽管道

建議您將 Chrome Canary、開發人員版或Beta 版設為預設開發人員版瀏覽器。這些預覽管道可讓您存取最新的 DevTools 功能，測試最新的網路平台 API，並在使用者發現問題前，協助您找出網站的問題！

與 Chrome 開發人員工具團隊聯絡

請使用下列選項討論新功能、更新或任何與開發人員工具相關的內容。