為什麼 Chrome 的基準測試勝利比分數更重要

Chrome 的最新基準測試破紀錄不只是成績單，而是證明瀏覽器工程仍能靠正確的優化方向持續變快。

我認為，Chrome 這次在 Speedometer 3.1 與 JetStream 3 的刷新，比單純的分數更重要，因為它證明瀏覽器效能仍然可以靠具體工程進步，而不是靠行銷話術。Google 公布的數據很直接：JetStream 提升 10%，達到 469 分；Speedometer 提升 5%，達到 61 分，測試平台是 MacBook Pro M5。這些提升不是靠一個炫技改動，而是來自 JavaScript、WebAssembly 與 Blink 的多點優化，說明現代網頁體驗的瓶頸已經深入編譯器、記憶體配置、DOM 快取與字串處理等細節。

第一個論點

基準測試之所以有價值，是因為它會逼工程團隊去修真正影響使用者體感的熱點。Chrome 這次針對 async fast path、排序、字串比較與 JavaScript 最佳化判斷做了優化，這些不是表面功夫，而是直接對準現代 Web App 最常卡住的地方。當一個頁面充滿 await、清單更新與資料轉換時，這些路徑就是使用者感受到「快」或「慢」的分水嶺。

渲染層也一樣。Chrome 把 querySelector() 快取統一、改善 style resolution、降低 transition 延遲，還用 SIMD 加速 HTML parsing 時的字串複製。這類改動不會出現在產品簡報的第一頁，但它們會反映在載入速度、互動流暢度與卡頓感上。當一個 benchmark 能獎勵這些路徑，它其實是在把整個瀏覽器產業往更接近真實體感的方向推。

第二個論點

WebAssembly 的進步更能說明，瀏覽器效能早就不是「頁面裝飾」的問題，而是平台能力的問題。Google 這次改善了 V8 對 SIMD 指令的 code generation 與 register allocation，對 AI、密碼學與 interpreter 類工作負載都有幫助；同時也降低 compiler 的記憶體重用開銷，並減少 JavaScript 與 WebAssembly 之間反覆轉換的成本。這代表 Wasm 不再只是展示技術，而是足以承載更重型的客戶端運算。

JetStream 3 把 BigInt 與 WebAssembly 這些弱點直接照亮，Chrome 再回頭修補，這正是 benchmark 應有的作用：先暴露缺口，再迫使平台補洞。當瀏覽器在 SIMD 密集與配置密集的工作上變快，開發者就能把更多邏輯留在瀏覽器內，不必把計算推回原生 App 或伺服器。這不只是更快，而是 Web 能做的事變多了。

反方可能怎麼說

最強的反對意見是，benchmark 會扭曲工程優先順序。Speedometer 和 JetStream 都是精心設計的測試，團隊很容易為了分數去過度優化。瀏覽器即使在測試裡拿到漂亮成績，真實使用者仍可能被外掛、差勁的網站程式、網路延遲或電池耗電拖累。這個批評成立，因為 synthetic benchmark 本來就不可能涵蓋所有痛點。

另一個合理質疑是，分數提升不等於整體品質提升。若團隊把資源都拿去追 benchmark，可能犧牲相容性、穩定性或安全性，而這些往往比多 5% 的跑分更重要。對使用者來說，瀏覽器偶爾快一點，不如長期可靠、少出錯來得有價值。

但這些批評只能提醒我們不要把分數當目的，不能否定 Chrome 這次成果的含金量。這次改善不是單點作弊，而是橫跨 JavaScript、WebAssembly 與渲染管線的系統性優化，對應的是實際使用者路徑。更準確地說，benchmark 是 proxy，不是終點；可是一旦 proxy 與真實引擎改動一致，分數就是有效證據，而不是表演。

你能做什麼

如果你是工程師，不要把瀏覽器效能當成平台團隊的責任，請直接用 async-heavy code、DOM churn、字串處理與 Wasm hot path 去量你的產品；如果你是 PM 或創辦人，請把前端效能當成產品指標，而不是技術備註，少做不必要的 client-side 操作，在功能膨脹前先要求 profiling，並接受一個事實：你在瀏覽器裡浪費的每一毫秒，最後都會變成轉換率與留存率的稅。