簡單來說，瀏覽器圖形基準測試就是盡可能多地繪製圖形，同時維持流暢的影格速率。一旦影格速率下降，您就會知道每個影格可繪製的內容量。結束貼文。沒有？好的，我會進一步說明。
舉例說明！以下是包含基準測試 tick 函式的程式碼片段。tick 函式會以遞增的繪圖負載呼叫 draw 函式，直到繪圖時間持續超過 33 毫秒為止。
var t, previousTime;
var drawLoad = 1;
var slowCount = 0;
var maxSlow = 10;
// Note, you might need to polyfill performance.now and requestAnimationFrame
t = previousTime = performance.now();
var tick = function() {
var maximumFrameTime = 1000/30; // 30 FPS
t = performance.now();
var elapsed = t - previousTime;
previousTime = t;
if (elapsed < maximumFrameTime || slowCount < maxSlow) {
if (elapsed < maximumFrameTime) {
drawLoad+=10;
} else {
slowCount++;
}
draw(drawLoad);
requestAnimationFrame(tick);
} else {
// found maximum sustainable load at 30 FPS
document.getElementById('res').innerHTML = ("could draw "+(drawLoad)+" in " +
maximumFrameTime + " ms");
}
};
requestAnimationFrame(tick);
您可以看到基準測試如何不斷繪製，直到達到速度變慢的點為止。這是一種簡單又實用的方式，可讓您瞭解在流暢的幀率下，您可以繪製多少內容。您也可以將自己的繪圖函式插入範例，並進行一些自訂基準測試，太棒了！
進行瀏覽器圖像基準測試時的常見注意事項和陷阱
因此，如果上述範例是正確的做法，那麼哪些做法是不正確的呢？導致您評估不相關項目或產生奇怪的效能指標，這些指標似乎與應用程式執行速度無關。很高興你問了這個問題，以下是我在網路上看到的兩個最常見問題。
測量最高 FPS：每個影格都繪製一點點內容，並測量 FPS。這項測試無法有效評估 Chrome 的圖像效能，因為基礎圖像實作會與螢幕更新率同步 (因此每秒最多可獲得 60 次螢幕更新)。測量繪製呼叫速度也不太有幫助，因為 Chrome 的繪圖系統會將繪圖指令放入指令緩衝區，在下次螢幕重新整理時執行。
使用 setTimeout 評估繪圖效能也是另一個不良做法。在瀏覽器中，setTimeout 間隔的上限為 4 毫秒，因此最多只能達到 250 FPS。以往瀏覽器的最小間隔時間不同，因此您可能會看到非常不準確的瑣碎繪圖基準測試，顯示瀏覽器 A 以 250 FPS (最小間隔時間 4 毫秒) 執行，而瀏覽器 B 以 100 FPS (最小間隔時間 10 毫秒) 執行。很明顯，A 的速度比較快！不！很可能是 B 執行繪圖程式碼的速度比 A 快，假設 A 需要 3 毫秒，B 則需要 1 毫秒。由於繪圖時間小於最小 setTimeout 間隔，因此不會影響 FPS。如果瀏覽器以非同步方式算繪，則一切都會失效。因此，除非您瞭解自己在做什麼，否則請勿使用 setTimeout。
那麼該如何進行
比較理想的基準測試方式，是使用實際的繪圖負載，並加倍疊加，直到影格速率開始下降為止。舉例來說，如果您要編寫使用圖塊地形的俯瞰式遊戲，請嘗試在每個影格繪製圖塊地形，看看是否能以 60 FPS 執行。如果是，請增加負載 (每個影格繪製地圖兩次，中間清除)。繼續增加，直到 FPS 降至新的穩定水平。您現在已瞭解每個影格可繪製多少個圖塊地圖層。
不同圖形應用程式的需求不同，因此您應在編寫基準測試時考量這點。評估應用程式中使用的圖形功能。如果發現速度緩慢的情況，請盡量縮減重現該情況的程式碼，並在 new.crbug.com 提交錯誤報告 (如果速度應更快的話)。
如要瞭解如何編寫高效能網頁圖形程式碼，請參閱 Chrome GPU 團隊的 Nat Duca 和 Tom Wiltzius 在 Google I/O 2012 的演講。