Chrome 双跑分纪录到底怎么来的：V8 内联 async 快路径、Blink 缓存 querySelector——Speedometer 3.1 到 61 分、JetStream 3 到 469 分

6 月 4 日，Chromium 团队公布 Speedometer 3.1 拿到 61 分、JetStream 3 拿到 469 分，双双刷新所有浏览器的纪录——而这轮从年初开始的提升，没有加入任何用户可见的新功能。

两个分数的来龙去脉

JetStream 3 自 2026 年初上涨 10% 到 469 分，Speedometer 3.1 自上次公布上涨 5% 到 61 分，均在一台 M5 MacBook Pro（macOS 26.0.1）上测得。按官方口径折算，JetStream 3 大约从 426 分涨到 469 分，Speedometer 3.1 大约从 58 分涨到 61 分。

「跑分涨了跟用户有什么关系」——这次有两组数据可以对上：Chromium 此前披露，Speedometer 分数与真实用户 P99 交互延迟的统计相关系数约为 -0.8（分数越高、延迟越低）；2026 年 7 月 Chromium 安卓侧的博客显示，旗舰机型上跑分提升转化成了 4%–6% 的真实页面加载提速和 6%–9% 的高分位交互响应提速。这 10% 不是营销数字。

V8：把最常见的绕路砍掉

官方把这轮优化分成三块，第一块是 JavaScript 引擎。V8 的做法是在优化编译器里为常见操作内联「快路径」——规范要求的完整实现仍然保留，但绝大多数调用走的是缩短后的路径。影响最大的是 async：微任务派发（microtask dispatch）和 await 解析被内联成快路径，排序和字符串比较也用了同样的手法。

// 场景：中后台表单提交后的串行请求，一次交互触发多次 await
async function submitAndRefresh() {
  const res = await fetch('/api/orders', { method: 'POST', body });
  const data = await res.json();  // 每次 await 都走一遍微任务派发
  await renderTable(data);        // 每次解析都是一次引擎内部调度
}
// 同样的代码在新版 Chrome 里，每个 await 点少走若干引擎内部步骤

async 密集的页面（无限滚动、实时协作、表单流）收益最直接。第二处是 BigInt：JetStream 3 上线后暴露了 V8 一直存在的缺口——BigInt 的除法和规范化（canonicalisation）没被优化到位，这轮一并重写，顺带调整了相关数据结构的分配方式，还加固了沙箱。前端做大数校验、哈希运算的场景会直接受益。

Blink：querySelector 上了统一缓存

渲染引擎这一块对前端感知最强：

• 统一 querySelector() 缓存：框架反复按选择器取节点，以前每次调用都要重新匹配，现在同一选择器在 DOM 未变时直接命中渲染引擎内部缓存；
• 属性处理加快速退出路径，元素没有属性时直接跳过一批检查；
• dataURI 资源缓存扩展到单文档之外，内联 SVG 图标多的现代框架直接受益；
• HTML 解析用上 SIMD 字符串拷贝，首屏从原始文本构建 DOM 的开销下降。

WebAssembly 一块主要是 SIMD 代码生成和寄存器分配优化，官方点名 AI、加密、解释器类负载受益；JavaScript 调 WebAssembly 的循环里，重复的类型转换也更容易被编译器消除。

下一步：量出自己的数字

这轮优化从 2026 年上半年陆续进入 Chrome 稳定版。想确认自己有没有吃到红利，做两件事：

1. 打开 browserbench.org 跑一次 Speedometer 3.1，用 Chrome stable 和 Beta 各跑 3 次取中位数（同一台机器、关掉多余标签页），对比版本间的差距；
2. 用 PageSpeed Insights 查自己站点的 INP P75——如果引擎优化真实生效，field 数据会在几周内跟着动。