瞭解如何評估動畫、如何考量動畫影格和整體頁面流暢度。
您可能曾經遇到「延遲」網頁或「凍結」或瀏覽其他內容 動畫。我們不希望這類體驗流暢，收件者地址 而 Chrome 團隊一直在努力增加支援 進而改善了動畫偵測工具 以及 Chromium 中的轉譯管道診斷結果
我們很樂意分享最近的進展，並提供具體的工具指引。 討論未來動畫流暢度指標的建議。一如既往 聽取意見回饋。
這篇文章涵蓋三個主要主題：
- 快速查看動畫和動畫影格。
- 我們目前對於評估動畫整體流暢度的想法。
- 您現在可以在研究室工具中運用一些實用建議。
什麼是動畫？
動畫讓內容更生動！讓使用者移動內容，尤其是在回應時 動畫可以帶來更自然的體驗 不僅容易理解，而且很有趣
然而，效能不佳的動畫 或加入太多動畫 破壞體驗，使人人覺得毫無樂趣。我們可能都懂 互動後發現有太多「實用」的介面轉換 反之，當效能不佳時，反而會對體驗造成不利的影響。 因此，有些使用者 偏好減少動態效果，使用者偏好 您應該尊重的事情
動畫如何運作？
這裡快速複習一下「轉譯管道」 由幾個「依序」階段組成：
- 樣式：計算 套用任何樣式
- 版面配置：產生 每個元素的幾何和位置。
- 小畫：請填寫 產生每個元素的像素數
- 複合：繪製 層層疊加
雖然定義動畫的方法有很多種，但基本上是透過 下列其中一項：
- 調整版面配置 資源。
- 調整油漆 資源。
- 調整 複合 資源。
由於這些階段是依序排列，因此在定義動畫時 點進單點屬性。更新時間 成本越高，成本就越高 流暢。(請參閱轉譯 效能 )。
為版面配置屬性建立動畫是很方便的做法，但需要 就算無法立即看出這些費用動畫 針對複合屬性變更。
定義宣告式 CSS 動畫或使用 Web 動畫、 同時確保合成動畫 資源 是確保動畫流暢度和效率的絕佳第一步。但現在 光是這項產品並不保證「流暢」 有效能限制這正是衡量成效的重要性！
什麼是動畫影格？
更新的視覺呈現方式需要一段時間才會顯示。影像 這樣就會產生新的動畫影格，最終在 螢幕。
顯示每隔一段時間的更新，以批次方式更新視覺更新。多種螢幕 採固定的時間間隔更新，例如每秒更新 60 次 60 Hz)。部分新型螢幕的刷新率更高 (90–120 Hz 很常見)。這些螢幕通常可以主動調整 或提供完全可變的畫面更新率
任何應用程式 (例如遊戲或瀏覽器) 的目標，都是將這些內容 批次更新視覺呈現，並在其中產生視覺效果完整的動畫影格 每次期限都一樣請注意，這個目標與其他 瀏覽器的重要工作 (例如從網路快速載入內容)， 有效率地執行 JavaScript 工作。
有時可能會難以完成 顯示畫面指派的分配期限在這種情況下，瀏覽器 捨棄影格螢幕不會變成黑色，只是重複播放。你會看到 同樣的視覺更新會稍微延長 - 同樣的動畫影格 也就是上一個影格商機
這種情況經常發生！這不見得很容易察覺，尤其是 是靜態或類似文件的內容，在 Google 網路平台通用的 。只有重要視覺元素才會清楚顯示捨棄的影格 例如動畫 這類動態更新 更新應用程式，顯示流暢的動態效果。
哪些因素會影響動畫影格？
網頁開發人員可以大幅改變瀏覽器 有效率地呈現及呈現視覺化更新！
以下提供一些例子：
- 使用過大或需要大量資源的內容，而無法快速解碼 目標裝置。
- 使用過多 圖層 所需的 GPU 記憶體過多
- 定義過於複雜的 CSS 樣式或網路動畫。
- 使用設計反模式，停用快速轉譯最佳化。
- 在主執行緒上執行太多 JS，導致長時間工作妨礙視覺操作 更新。
但是，如何得知動畫影格錯過期限， 掉落的影格？
其中一種方法是使用
requestAnimationFrame()敬上
但也有多項缺點requestAnimationFrame()，或稱「rAF」
會告訴瀏覽器你想播放動畫，並要求
直到模型的下一個繪製階段完成如果
系統就不會在您預期時呼叫回呼函式，這表示
未執行繪製，並略過一或多個影格。藉由輪詢
計算呼叫 rAF 的頻率，您就可以計算「每秒影格數」
(FPS) 指標。
let frameTimes = [];
function pollFramesPerSecond(now) {
frameTimes = [...frameTimes.filter(t => t > now - 1000), now];
requestAnimationFrame(pollFramesPerSecond);
console.log('Frames per second:', frameTimes.length);
}
requestAnimationFrame(pollFramesPerSecond);
我們不建議使用「requestAnimationFrame()」輪詢，原因如下：
- 每個指令碼都必須設定自己的輪詢迴圈。
- 可以阻擋重要路徑。
- 即使 rAF 輪詢作業相當快速
requestIdleCallback()敬上 無法在持續使用後，安排長時間的閒置區塊 (會封鎖 而非單幅畫面) 上 - 同理，閒置久度的閒置時間過長會讓瀏覽器無法安排其他 長時間執行的工作 (例如更長時間的垃圾收集和其他背景) 投機性研究)。
- 如果已開啟及關閉意見調查功能，就會錯過影格預算的情況 。
- 如果瀏覽器使用 變數更新頻率 (例如因為電源或顯示狀態的關係)。
- 最重要的是，這項功能無法擷取所有類型的動畫。 更新！
如果主要執行緒執行過多工作，可能會影響系統顯示動畫影格的功能。 試試看 Jank 範例瞭解 如果主執行緒有太多工作，就會以 rAF 驅動的動畫效果 (例如 會導致捨棄影格、降低 rAF 回呼，以及降低每秒影格數。
當主執行緒當機時，視覺更新會開始延遲。 那是卡頓！
很多評估工具都著重在 才能及時產生執行緒，讓動畫影格順暢運作。 但這不是一切！請參考以下範例：
上方影片顯示的是一個網頁定期將大量工作插入主要內容
。這些長時間執行的工作會完全破壞頁面
您也應該從左上角查看
requestAnimationFrame() 回報每秒影格數的對應率下降至 0。
但即使進行了這些長時間工作，頁面仍能順暢地捲動。這個 因為在新式瀏覽器上，捲動作業通常 執行緒 完全是由合成器驅動
這是在主執行緒中同時包含許多捨棄影格的例子 但在執行緒上仍有許多成功傳遞的 產生關聯執行緒長時間工作完成後，主執行緒繪製作業就會更新 也不會變更視覺元素rAF 輪詢作業建議將影格降至 0， 但無論視覺效果為何，使用者都不會看到任何差異！
製作動畫影格的故事並不簡單。
動畫頁框：重要更新
上面的例子可以說明故事內容不僅限於
requestAnimationFrame()。
動畫更新和動畫影格的重要性為何？以下 一些我們正在考慮的準則，也希望瞭解以下方面的意見：
- 主要和合成器執行緒更新
- 缺少油漆更新
- 偵測動畫
- 品質與數量
主要和合成器執行緒更新
動畫頁框更新不是布林值。有時候，影格只會在 完全捨棄或完全呈現動畫的原因有很多 影格可能會部分 顯示。換句話說 網頁過時內容，同時有一些新的視覺設計更新， 。
最常見的例子就是瀏覽器無法產生新的 主要執行緒在影格期限內更新，但有新的合成器執行緒 (例如前述的執行緒捲動範例)。
使用宣告式動畫建立複合元素動畫的一大原因 建議屬性讓動畫可以驅動 完全由合成器執行緒執行，即使主執行緒處於忙碌狀態也是如此。這些類型 不斷有效率提升 平行。
另一方面，在某些情況下，主執行緒更新最終會變成 這類圖表只能呈現在缺少多個影格期限這裡 瀏覽器會有「部分」更新，但不是最新版本。
一般而言，考量包含更新視覺元素的畫面 沒有所有新的視覺更新，做為部分頁框。部分影格公平 理想情況下，部分更新至少會包括 視覺更新，例如動畫，但只有在動畫 源自於合成器執行緒。
缺少油漆更新
圖片等媒體未播放完畢時，也是另一種部分更新類型 包括在影格簡報中 執行解碼和光柵化處理
或者，即使網頁是相當靜態的網頁，瀏覽器仍可能無法轉譯 在快速捲動的過程中更新視覺設計這是因為像素採用時 系統可能會捨棄可視區域以外的內容，以節省 GPU 記憶體。這項服務 需要時間才能顯示像素 而且可能需要超過一個畫面 進行大型捲動後，所有內容都會轉譯，比如手指滑過手指。這通常 也稱為檢查工具。
在每次有人顯示影格轉譯時，您可以追蹤 其實已經在畫面上顯示最新的視覺更新衡量達成這項目標的能力 影格數量 (或時間) 廣泛，普遍稱為「影格處理量」。
如果 GPU 當機，瀏覽器 (或平台) 甚至可能開始啟動 對嘗試視覺更新的頻率限制，進而減少 有效影格速率嚴格來說，在技術上可以 影格更新後，影格處理量仍會顯示為較差的影格處理量。
不過，並非所有類型的低影格處理量都是不佳的。如果網頁大多處於閒置狀態 而且沒有正在運作的動畫，低畫面更新率就和視覺上的一樣 因此能降低畫面更新率 (而且能節省電力！)。
那麼影格處理量在何時很重要？
偵測動畫
高影格處理量至關重要，尤其是在重要期間 動畫。不同的動畫類型將依附於 特定執行緒 (主要、合成器或 worker)，所以視覺更新 隨後依附於該執行緒，在期限內提供更新。假設 每當有播放中的動畫時，指定的執行緒就會影響流暢度 就會視執行緒更新而定
某些類型的動畫更容易定義及偵測。 宣告式動畫，或使用者輸入的動畫，會更清楚地定義 比 JavaScript 動畫更適合定期更新以動態方式更新 樣式屬性。
requestAnimationFrame() 也能享有這項福利
不一定每次都會假設所有 rAF 呼叫都會產生視覺效果
更新或動畫例如，使用 rAF 輪詢程式追蹤畫面更新率
(如上所示) 本身不應影響流暢度的測量結果
沒有視覺更新
品質與數量
最後，偵測動畫和動畫影格更新的功能 原因在於它只反映了動畫更新的次數，而不是 品質
舉例來說，你在觀看影片時，可能會發現影格速率穩定為 60 fps 影片。技術上來說，這種情況相當流暢，但影片本身 低位元率，或網路緩衝處理發生問題。不適用於 但對於動畫流暢度指標而言 內容。
或者，如果遊戲採用了 <canvas> (也許會使用
螢幕外
畫布 變更為
以確保畫面更新率) 在技術上
但無法將高品質的遊戲資產載入
或展示成像模型
當然，網站偶爾會有一些很糟糕的動畫 🙂?
我想，他們們在這時都很酷！
單一動畫影格的狀態
因為可能呈現部分影格，或影格遺失的 不影響流暢度，因此我們開始將每個影格視為 完整性或平滑分數
以下是我們解讀單一狀態 動畫頁框，依最佳到最差情況排序：
| 不想要更新 | 閒置時間，重複上一個影格。 |
| 完整展示 | 主要執行緒更新是在期限內修訂，或 需要更新主執行緒。 |
| 部分展示 | 僅限合成器；延遲的主執行緒更新沒有視覺說明 變更。 |
| 部分展示 | 僅限合成器；主執行緒有視覺更新 更新並未包含會影響流暢度的動畫。 |
| 部分展示 | 僅限合成器；主要執行緒的視覺更新 平滑化，但使用之前過時的影格，現已改用。 |
| 部分展示 | 僅限合成器；無須進行主要更新 合成器更新內含會影響流暢度的動畫。 |
| 部分展示 | 只有合成器，但合成器更新沒有 影響流暢度的動畫 |
| 捨棄的影格 | 沒有更新。沒有任何所需的合成器更新，主要是 延遲時間。 |
| 捨棄的影格 | 想要更新合成器，但延遲更新。 |
| 過時影格 | 需要更新，是由轉譯器產生 GPU 未在 vsync 期限前顯示。 |
您可以把這些狀態轉換為分數。有些則差不多 也就是將此分數視為可能性 使用者。捨棄的影格可能不見得非常可觀察到，只有一連串的影格 捨棄的影格中有許多會影響資料列流暢度的問題！
總整理：捨棄的影格百分比指標
雖然有時候可能必須深入瞭解每個項目的狀態 此外，您也可以只指派「快速瀏覽」按鈕分數 或個人經驗
因為影格有可能部分呈現，而且因為即使完全略過 影格更新可能無法實際影響流暢度，我們希望減少關注的重點 只會計算影格數，以及瀏覽器無法遇到的極端情況 必要時，提供視覺化完整的更新。
這個心理模型應從：
- 每秒影格數 -
- 偵測遺漏和重要的動畫更新，
- 在特定時間範圍內的下降百分比。
重要的是：等待重要時間的比例 更新。我們認為這可以自然流暢地帶給使用者 大量網路內容目前為止，我們已使用下列項目做為 初始指標組合
- 平均捨棄百分比：在整個播放期間所有非閒置動畫影格 完整時間軸
- 捨棄的頁框百分比最差：以滑動時間超過 1 秒為例 時間範圍。
- 捨棄影格百分比的第 95 個百分位數：超過 1 秒 滑動視窗
您可以立即在部分 Chrome 開發人員工具中查看這些分數。雖然這些 指標只著重在整體影格處理量，我們也會一併評估其他 例如影格延遲時間
親自試用開發人員工具！
效能 HUD
Chromium 隱藏在標幟後方的完善效能 HUD
(chrome://flags/#show-performance-metrics-hud)。在這個例子中，你可以找到
包括 Core Web Vitals 的分數，以及一些實驗定義
。
影格轉譯統計資料
啟用「影格轉譯」 統計資料」 直接在開發人員工具中，查看新動畫影格的即時監控 系統會以顏色編碼，區分部分更新和完全捨棄的影格 更新。回報的每秒影格數僅適用於完整影格。
開發人員工具效能剖析檔中的影格檢視器
開發人員工具效能 面板 長邊的影格速率 檢視器。 然而，與現代算繪管道的差距不大 以及實際可行的。近期的改進幅度很大， Chrome Canary，我們認為可有效減少對動畫問題的偵錯作業。
今天你會發現，頁框檢視器中的頁框較符合 非同步界線，並根據狀態以不同顏色標示。距離不夠滿 以視覺化方式呈現上述所有細微差異，但未來預計會新增更多 不久的將來
Chrome 追蹤
最後，有了 Chrome 追蹤，這項工具就能深入解析
可以錄製「網頁內容轉譯」透過新的 Perfetto
UI (或 about:tracing)，並深入瞭解 Chrome 的
圖形管線。這可能會是一項艱鉅的任務，但您必須處理好幾件事
最近加入了 Chromium 中，目的是讓瀏覽變得更簡單。您可以使用總覽畫面
正所謂生活中
外框
文件。
您可以透過追蹤事件明確決定：
- 正在執行的動畫 (使用名為
TrackerValidation的事件)。 - 取得動畫影格的確切時間軸 (使用名為
PipelineReporter)。 - 針對卡頓動畫更新，找出造成使用者
加快執行速度的動畫 (使用
PipelineReporter事件)。 - 如為輸入導向動畫，則瞭解取得視覺更新所需的時間
(使用名為
EventLatency的事件)。
後續步驟
Web Vitals 計畫旨在為 打造絕佳的網路使用者體驗 以研究室為基礎的指標，例如「總計」 封鎖時間 (TBT) 非常重要 偵測及診斷潛在的互動問題。我們計劃 設計類似的研究室指標來呈現動畫流暢度
我們持續開發各種設計想法，敬請期待！ 根據個別動畫影格資料計算出的全方位指標。
日後，我們也想設計相關 API，方便您評估 動畫流暢度，在 field 和研究室中。 也請密切留意最新消息！
意見回饋
很期待最近加入的改善項目與開發人員工具 這是 Chrome 的新功能，可測量動畫的流暢度。請試著使用這些工具 設定動畫基準，請告訴我們它在哪裡！
您可以將意見傳送至 web-vitals-feedback Google 顯示「[Smoothness Metrics]」文字的群組做為主旨我們想要 期待您的回覆！