3D 效能數字的量測誤差與可信量法

同一個 3D 頁面，在載入期間量到的記憶體，約只有載入完成後的 1/3。載入期的畫布每邊只有最終尺寸的 0.6 倍，面積約 36%，其餘資源也還沒載完。這個數字不算錯，錯的是量測的時間點。若廠商的報告量在這個時間點，數字會比使用者實際遇到的好看許多。Web 3D 效能工程的整體做法講先量什麼、再改什麼，本文只談「量」這一步會出什麼錯。

開發團隊對效能數字只認三個條件：算繪在真 GPU 上，量測在載入完成之後，做完一輪操作能回到基線。缺任何一項，數字不納入比較。後文依序說明假數字的來源、關垂直同步造成的誤判、比較兩版的量法，以及檢查廠商效能報告時要看的條件。

假數字的來源

載入中的畫面

載入期間，場景還沒完整，畫布尺寸、貼圖與幾何都在逐步到位。這時量記憶體或幀率，量到的是半成品。量測腳本要先斷言載入完成，再開始取樣。

兩版的比較也要用同一支腳本。開發團隊的做法是各版本各自建置，由同一支腳本量測，不憑記憶中的舊數字比較。以一個互動 3D 產品頁為例，舊版量到約 800 MB，新版量到約 690 MB，兩個數字出自同一支腳本，記憶體確實是減少了。

隱藏分頁

瀏覽器在多數情況下，會暫停背景分頁與隱藏 iframe 中的 requestAnimationFrame 回呼，以節省效能與電量，MDN Web Docs，2026有相關說明。繪製迴圈若依賴這個回呼，隱藏分頁中量到的幀率就不能直接當作使用者看到的實況。這一句是本文的推論，MDN 頁面並未討論幀率量測。

軟體算繪

沒有 GPU 時，Chromium 可以改由 SwiftShader 在 CPU 上以軟體方式畫 WebGL 內容。Chromium 專案文件說明了這個機制，並註明自動退回 SwiftShader 已棄用，WebGL 建立可能直接失敗。headless 瀏覽器在預設設定下走軟體算繪，開發團隊實測只有約 1 至 3 fps，還會把 KTX2 壓縮貼圖解成 RGBA，記憶體數字被灌得很高。文件沒有談軟體算繪的效能是否代表真機，所以「不能代表」是依上述實測得出的推論。

隱藏分頁與軟體算繪同時發生，數字會荒謬到一眼可辨：所有設定的幀時間完全相同，或量到每秒約 2,200 幀，遠超過一般螢幕的更新率。

量錯行程

Chrome 分頁的「記憶體用量」是分頁行程的數字，不含 GPU 行程，所以兩個行程都要量。以同一個產品頁為例，桌機像素比上限調低之後，GPU 行程的記憶體少了約 70 MB，這部分變化不在分頁行程的數字裡。該次量測使用 Playwright 無頭模式搭配真 GPU，由 CDP 取得行程後以 top 讀取記憶體。無頭模式本身不是問題，關鍵在是否取得真 GPU。

數字正常，內容卻是空的

有些失敗不報錯。有的高斯潑濺檢視器在啟用細節層級（LoD）時，等了約 6 秒仍得到 0 個高斯，沒有丟出任何錯誤；不啟用 LoD 時，同一份資料得到約 300 萬個。若腳本只記錄耗時，空場景會被記成一筆正常的數字。量測要同時斷言內容真的畫出來，例如繪出的高斯數量大於 0。

回到基線

單看絕對值，很難說多少才算正常。更可靠的判準是做完一輪操作之後，有沒有回到基線。疊加測試重複 4 輪，每輪結束後數幾何、貼圖與著色器 program 的數量，數量持平，表示沒有隨操作疊加。

關垂直同步造成的誤判

垂直同步讓繪製節奏對齊螢幕更新，常見為 60 Hz。關掉垂直同步與幀率上限後，GPU 負擔重的畫面會讓 CPU 一直停在等 GPU。量測看到的是 render 每次耗時很長，容易被解讀成程式本身慢，實際上是 CPU 在等待。

以一個要在手機上順的 3D 地圖為例。關垂直同步量，入場後每次 render 約 20 ms，看起來像「第一次畫每個東西的成本」，容易因此考慮分片預熱來攤開這筆成本。改成開垂直同步量，入場後前 40 次 render 只有約 1 至 6 ms，原有的預先編譯加預熱已經夠用。分片預熱沒有可量的好處，標為不採用。

卡頓要先分類再處理。開發團隊用 Chrome trace 搭配 V8 取樣，把卡頓格分到 JavaScript、樣式重算、排版、繪製、垃圾回收，以及等 GPU 幾類。桌機上約 300 ms 的長幀，分類後發現主因是瀏覽器啟動音訊裝置本身；拿掉這一步，長幀只剩約 30 ms。沒有分類，這個長幀很容易被當成程式碼的問題。

比較兩版的量法

單次量測的雜訊，可能比改善幅度還大。機器上有其餘工作在跑、系統負載（load average）高到數十至上百時，每區卡頓格占比的底噪就約 2%。改善幅度只有幾個百分點時，這樣的底噪足以蓋過改善，單次格數因此不能比。最長幀與 trace 裡的 JavaScript 毫秒受影響相對較小，但仍要靠多輪確認。

1. 開垂直同步，在真實的 60 Hz 條件下量。
2. CPU 降速 4 倍來模擬手機，並照實標明是模擬與降速倍率。
3. 先量底噪：同一個版本重複量測，看數字自己散布多大。改善幅度小於這個散布，不下結論。
4. 兩個建置交錯 A/B，讓雜訊平均分給每個版本。
5. 多輪取中位數，不取單次最佳值。

這不是 3D 獨有的問題。Mytkowicz 等人的論文主張，實驗設定中看似無關緊要的細節，就會讓系統研究者得出錯誤的結論，這稱為量測偏差；作者在多種架構與編譯器上都觀察到這個現象（Mytkowicz 等，2009）。

效能比較要用統計方法，不能看單次。Georges 等人針對 Java 的效能評估提出這個主張（Georges 等，2007），論文所舉的例子是：只取 30 次中的最佳值，兩種垃圾回收器看起來相近；改用 95% 信賴區間分析，其中一種明顯較好。本文僅引述其主張與所舉的例子，不延伸到全文結論。重複次數則要依變異決定：Kalibera 與 Jones，2013用實驗成本模型，求出在指定精度下必要且足夠的各層重複次數，並指出重複最有用的地方是不確定性最大的環節。

優化要能被否決

量測的另一個用途是否決優化。沒量到好處的調整，標成「不採用」，連同量測條件與原因一併寫下，避免下一個人重做。上文的分片預熱就是一例。

降解析度是常見的調整，但只在瓶頸是像素時有效。一個互動 3D 產品頁實測，像素降到 36%，桌機幀時間只少約四分之一；每次切換解析度還要重新配置繪圖緩衝，降加升一次約 20 ms，損益兩平要連續拖曳約 370 ms。因此只在載入期降解析度，互動時不降。

鏡頭移動時降低水面倒影的更新頻率，在模擬手機（CPU 降速 4 倍、開垂直同步、兩版交錯）下，拖曳時每幀 JavaScript 時間約少 2 ms。這類改善以毫秒計，所以條件要寫清楚。同一批工作中，替地標與圖示按鈕加上 will-change: transform，A/B 沒有差別，說明文件寫明不要再試。

否決也發生在更大的尺度。高斯潑濺漫遊若用 mesh 先寫入深度、剔除牆後的高斯：遮擋模型與掃描資料在牆與地板對得上，室內物件的位置卻對不上，眼高時近物占畫面比例大，誤差被放大成大面積破洞。這類室內掃描資產行不通，預設關閉並記下原因，避免重複投入。

MDN 文件對 WebGL 的建議（MDN Web Docs，2026）分三部分：減少 draw call、控管貼圖記憶體、先編譯再連結著色器。頁面給的是原則，沒有實測數字，所以這些建議能指出先看哪裡，某項調整在特定場景有沒有用，仍要自己量。

記憶體有變化時，還要知道變化來自哪裡。開發團隊用 heap snapshot 找 ArrayBuffer 節點，沿 retainer 往上找第一個已知類別。一次調整中，GLB 解析完畢並釋放 parser 之後，ArrayBuffer 由約 230 MB 降到約 160 MB，歸因因此有依據。模型端的優化前後對照另見3D 模型優化前後的對照。

檢查廠商效能報告的條件

評估廠商的效能報告時，先看條件，再看數字。下表列出每項條件、應該看到的內容，以及缺少時的風險，可搭配挑選軟體廠商的評估方式使用。

表中任何一項寫不出來，數字仍可能是真的，只是沒有辦法判斷。開發團隊在3D 開發服務中，以這套條件量測效能。

不適合的情況

• 頁面沒有互動 3D：一般的 Web Vitals 工具就足夠，不需要本文的交錯與多輪做法。
• 只要一個數字放進簡報，且不需要被重現：單次量測就夠，不必做交錯與多輪，但真 GPU 與載入完成這兩項前提仍要守。

下一步

要準備的是現有的效能報告與其量測條件，以及最在意的裝置。想先看開發團隊做過的專案，可參考磨人的案例；準備好了，就與開發團隊聯絡。