我測(cè)了Pretext.js：瀏覽器基準(zhǔn)測(cè)試不會(huì)告訴你的事

　　幾年前——按現(xiàn)在的標(biāo)準(zhǔn)感覺(jué)像上古歷史了——Twitter上吵得火熱的是Pretext.js，一個(gè)文本布局庫(kù)。它的 headline 聲稱(chēng)比標(biāo)準(zhǔn) DOM 測(cè)量快得多：不讓瀏覽器布局引擎計(jì)算文字尺寸，而是在純 JavaScript 里完成等價(jià)工作，數(shù)據(jù)通過(guò) prepare() 一次性準(zhǔn)備好。理論上，每次測(cè)量都不會(huì)觸發(fā)強(qiáng)制重排。

　　不同人的演示看起來(lái)都很 impressive，我好奇實(shí)際到底有多快。只有一個(gè)問(wèn)題：我并不擅長(zhǎng)性能測(cè)量。除了基礎(chǔ)的 Core Web Vitals 工作——LCP、INP 這些常規(guī)指標(biāo)——我對(duì)這種微基準(zhǔn)測(cè)試毫無(wú)經(jīng)驗(yàn)。

　　我開(kāi)始研究這些測(cè)量到底怎么做，結(jié)論是應(yīng)該從最簡(jiǎn)單的測(cè)試開(kāi)始：比較三種策略的單次調(diào)用成本——DOM、Canvas、Pretext。

　　我選了最精簡(jiǎn)的配置，避免測(cè)試框架本身拖累運(yùn)行時(shí)：Astro 靜態(tài)輸出，只在需要交互的地方用 React 孤島，手寫(xiě)測(cè)量工具。我為每種策略寫(xiě)了最小實(shí)現(xiàn)，開(kāi)始跑測(cè)試。

　　以下是我學(xué)到的東西。幾乎都和 Pretext 無(wú)關(guān)。

　　第一輪基準(zhǔn)測(cè)試結(jié)果長(zhǎng)這樣：大部分格子顯示零。不是零的那些 suspiciously 整齊——正好 100.00、200.00、400.00。這些整數(shù)是線索。

　　2018 年 Spectre 漏洞披露后，瀏覽器故意降低 performance.now() 的精度，讓基于計(jì)時(shí)的內(nèi)存攻擊更難。Chrome 把計(jì)時(shí)器四舍五入到約 100 微秒，F(xiàn)irefox 和 Safari 約 1 毫秒。你可以在控制臺(tái)驗(yàn)證：

　　console.log(performance.now() % 1)
// Chrome: ~0.1 遞增
// Firefox: 0

　　我一直在基準(zhǔn)測(cè)試某些情況下不到 1 微秒就完成的操作。當(dāng)然返回零——計(jì)時(shí)器根本沒(méi)有更小的單位來(lái)表達(dá)。

　　crossOriginIsolated 頁(yè)面可以通過(guò)基于 SharedArrayBuffer 的時(shí)鐘解鎖約 5 微秒計(jì)時(shí)精度，但設(shè)置 COOP/COEP 響應(yīng)頭很麻煩。批量計(jì)時(shí)在不碰響應(yīng)頭的情況下達(dá)到同樣的有效精度。

　　正經(jīng)基準(zhǔn)測(cè)試庫(kù)（benchmark.js、tinybench、criterion 風(fēng)格框架）的標(biāo)準(zhǔn)修復(fù)方案是批量計(jì)時(shí)。不是每次調(diào)用單獨(dú)測(cè)，而是測(cè) N 次調(diào)用的批次再除以 N：

　　// 我之前寫(xiě)的——有問(wèn)題
for (let i = 0; i < 1000; i++) {
const t0 = performance.now()
measure()
timings.push(performance.now() - t0)
}

　　// 應(yīng)該是這樣
const BATCH = 1000
for (let i = 0; i < iterations; i++) {
const t0 = performance.now()
for (let j = 0; j < BATCH; j++) measure()
timings.push((performance.now() - t0) / BATCH)
}