为什么浏览器游戏感觉卡顿（以及如何修复）

在原生游戏里，你的鼠标点击几毫秒就能到达。而在浏览器游戏里，同一次点击要先在操作系统、JavaScript 引擎和合成器后面排队，才能变成一个像素。本文讲清浏览器在哪里加了延迟、如何测量属于你的那份延迟，以及真正能改动数字的修复方案。

输入链路：从微动到像素

你的每一次点击都在一条流水线上旅行。每个环节都会加上自己的延迟，而浏览器正坐在流水线中段：

加起来，60Hz 设备上的浏览器游戏，在游戏逻辑本身还没做任何事情之前，点击到成像的延迟就可以达到 40-60ms。使用原始输入的原生游戏则直接跳过其中好几个环节。这个差距，正是同一只鼠标在桌面上干脆利落、在浏览器标签页里拖泥带水的原因。

显示税：看到任何东西之前先交 16.7ms

有个事实值得在开黑时分享：在 60Hz 下，仅显示器就能在你的点击可见之前增加最多 16.7ms——整整一帧的延迟。仅这一个环节的代价，就超过了一只游戏鼠标的整条管线：好的光微动约 1ms 触发，1000Hz 轮询再加 1ms。

人们乐此不疲地花 150 美元给鼠标抠掉 2ms，却把 16.7ms 留在显示器设置里没人管。换到 144Hz，帧税降到 6.9ms；240Hz 时是 4.2ms。如果你的显示器有这个能力却被配置错了——这种情况普遍得令人沮丧——我们的真实刷新率检查指南只要两分钟。

这并不是说鼠标不重要。它的意思是：延迟是花在整条链路上的预算，而金额最大的那几个条目，往往营销做得最少。

测量浏览器占的那份延迟

修不了你无法隔离的东西。我们的浏览器输入延迟测试测量的正是浏览器自己拥有的那一段：它把每个输入事件的时间戳与事件处理函数实际运行时的高精度时钟做对比，然后在一批点击、触摸或按键上给出中位数和第 95 百分位。

结果这样读：中位数是你的典型分发延迟——健康的桌面浏览器通常在低个位数毫秒。p95 是尾部——主线程打嗝时有多糟。中位数 2ms 而 p95 高达 30ms，意味着你的浏览器平时没问题但经常卡顿，反映在游戏里就是随机吞输入。

要诚实面对它的测量范围：这是浏览器事件边界上的分发延迟，不包含鼠标微动、USB 传输或屏幕扫描输出——工具自己的说明部分也是这么写的。想看完整的端到端图景，读完本文后再过一遍输入延迟清单。

为什么同一只鼠标在浏览器里手感更差

原生游戏贴着金属读输入——原始输入 API 以最少的仪式拿到鼠标数据。浏览器走的则是观光路线。操作系统把事件交给浏览器，浏览器判断光标下面是哪个元素（对整个 DOM 做命中测试），再把它分发到主线程上的 JavaScript，只有到这一步你的游戏代码才能做出反应。如果主线程正忙着执行广告脚本，你的点击就得排队。

三个浏览器特有的放大器：

• 繁忙的主线程：沉重的标签页、视频广告和各种页面脚本，都和你的游戏共享同一条线程。一个后台标签页放着静音视频，就能给每一次输入加上肉眼可见的抖动。
• 扩展程序：每个监听页面事件的扩展都会给分发加活。语法检查器和优惠券注入器是惯犯。
• 事件合并：浏览器会把高频的指针移动事件打包成组发送。纸面上有利于流畅度，实际上意味着你的瞄准数据是一坨一坨到达的。

这也是为什么同一把键盘在原生应用里指哪打哪，在浏览器里输入却感觉发绵——我们在我的键盘是不是卡了和更深入的键盘延迟解析里详细拆解过这个现象。

真正有效的修复方案

按效果大致排序：

• 开启硬件加速。Chrome/Edge 里：设置 → 系统 →“使用图形加速（如可用）”。把合成卸载到 GPU 值好几个毫秒，还能消灭大部分帧节奏问题。它默认应该是开的；公司策略和老驱动拉黑是它没开的常见原因。
• 让显示器跑在真实刷新率上。我们看到的“浏览器卡顿”报告里，一半都是 144Hz 面板卡在 60Hz。要验证实际呈现的帧，而不只是 Windows 里的设置。
• 关掉后台标签页、禁用扩展。尤其是任何播放媒体或注入页面脚本的东西。用一个干净的浏览器配置测试——如果 p95 立刻塌下来，那就是某个扩展在偷吃你的输入。
• 全屏运行。在大多数浏览器里，全屏窗口有更直接的合成路径，能省几毫秒，还能去掉桌面窗口管理器的开销。
• 外设优先用有线，别用蓝牙。蓝牙在所有环节之上还要再加约 10-20ms，外加偶尔的重传卡顿。2.4GHz 接收器和普通 USB 要紧致得多。
• 游戏提供指针锁定时就用它。指针锁定（pointer lock）能给浏览器游戏接近原始的鼠标增量数据，让移动绕过光标命中测试。

一次只改一项，每改完就重跑一次延迟测试。看着自己的 p95 从 25ms 掉到 6ms，比任何设置指南都有说服力。

垂直同步与帧节奏，一段话讲完

浏览器的渲染是垂直同步的：帧与你显示器的刷新步调一致地呈现。这是好事——防止画面撕裂——但它意味着游戏只能在帧边界更新，任何错过截止时间的帧都要多等整整一帧。60Hz 下错过一次的代价是 16.7ms；240Hz 下同样的错过只花 4.2ms。帧节奏不均，就是浏览器游戏报出“60 FPS”却仍然卡顿的原因：帧都在，只是到达的时间不均匀。高刷新率是最便宜的解药，因为它缩小了每一种可能失误的代价。

当锅不在浏览器身上

如果上面都做了游戏还是感觉不对，瓶颈在链路的别处。常见的非浏览器嫌疑犯：电视而不是显示器（不开游戏模式能加 30-80ms）、蓝牙键盘或鼠标、仍停留在 60Hz 的显示器、其他应用造成的高系统负载，或者——在网游里——纯粹的网络延迟，那是穿着同一件外套的另一个问题。20ms 的 ping 不是输入延迟，但你的手分不出来；我们的平均反应时间一文解释了为什么 20ms 正好卡在人类感知的边缘。

用输入延迟清单系统地排查整个系统：测量每个环节，改一个变量，再测一次。延迟排查只有在靠猜的时候才让人崩溃。

总结

浏览器游戏感觉卡，是因为浏览器里的一次点击比原生游戏走得更远——穿过命中测试、JavaScript 主线程、垂直同步的合成器，最后才是显示器。收益最大的修复都很无聊而且免费：开硬件加速、设对刷新率、杀后台标签页和扩展、开全屏、关蓝牙。测出你浏览器的分发延迟，修好你能控制的环节，然后才轮到怪游戏。大多数“卡顿的浏览器游戏”，其实是卡顿的浏览器配置。