这里测到的是浏览器侧系统处理延迟
本工具主要比较键盘事件的时间戳与浏览器 JavaScript 开始处理、再到下一帧渲染之间的时间差。它更接近“系统与浏览器这一段输入链路是否顺畅”,适合做网页环境下的相对比较与波动观察。
这个页面参考独立键盘测试站的“延迟页”思路实现,但会明确区分浏览器侧事件延迟与硬件实验室里的绝对输入延迟。
平均延迟
-- ms
抖动
-- ms
最低延迟
0.0 ms
最高延迟
0.0 ms
P95 延迟
0.0 ms
样本数量
0
按下任意键
推荐测试按键:空格键 / Enter / Shift
每次记录都会同时保留键位名、事件进入浏览器的排队延迟,以及到下一帧的大致视觉响应延迟。
图表展示最近 100 次样本,越低越接近快速稳定的网页侧响应。
输入延迟通常指从你按下物理按键开始,到系统或屏幕出现对应反馈之间所经历的时间。真正完整的键盘全链路延迟,往往需要高速摄像机、示波器、专用控制板或商业级输入延迟测试设备配合测量。这个页面不是去读 USB 硬件层的绝对触发时间,而是站在浏览器里,观察事件进入系统上层后的处理与渲染响应。
本工具主要比较键盘事件的时间戳与浏览器 JavaScript 开始处理、再到下一帧渲染之间的时间差。它更接近“系统与浏览器这一段输入链路是否顺畅”,适合做网页环境下的相对比较与波动观察。
纯 Web 页面无法直接读取开关导通、MCU 扫描、USB 传输以及显示器真实像素变化的完整物理链路。因此这里的结果不能直接当作键盘厂商宣传里的绝对延迟,也不适合拿来做硬件级定标。
即使平均值看起来不高,只要延迟忽高忽低,手感依然会变得不稳定。对游戏、节奏输入和高频操作来说,低抖动通常比偶尔刷出一次很低的样本更有参考意义。
键盘延迟并不是单一点位的问题,而是多段链路叠加后的结果。这个页面更偏向其中靠后的系统 / 浏览器 / 渲染部分,所以适合帮助你判断问题是否出在当前运行环境,而不是直接给出轴体或主控的物理极限。
轴体导通速度、磁轴触发行程、回弹和去抖参数都会影响最早的输入起点,但这些不是浏览器页面能直接看到的原始物理信号。
MCU 扫描频率、固件去抖策略以及无线 / 有线链路状态,会决定事件多久才能送到操作系统。这里依然属于更底层的输入路径。
本工具主要观测的就是这一段。操作系统把事件交给浏览器后,主线程负载、标签页状态、绘制队列和刷新率都会影响你在页面里看到的最终数值。
如果你想让当前页面里的结果更稳、更接近顺滑输入体验,优先从系统负载、显示链路和键盘连接方式下手,往往比反复刷新页面更有效。
浏览器主线程忙、后台标签页过多、录屏或下载任务过重,都容易把平均值和尖峰一起拉高。测试前尽量收一收后台任务,结果通常会更干净。
如果你已经有还不错的平均值,下一步更值得看的通常是抖动。保持电源模式稳定、减少标签页切换、避免测试过程中频繁唤起通知,比单纯追最低值更重要。
有线连接、稳定的 2.4G 接收器位置,通常都比高干扰环境下的蓝牙更容易拿到稳定样本。如果你怀疑是设备本身问题,也建议对比不同连接模式再看结果。
如果你要判断真实的键盘全链路输入延迟,或者想验证宣传参数是否属实,还是需要借助高速摄像、示波器或专业输入延迟测试设备。这个页面更适合做日常自检、环境比较和异常排查。
下面这些问题主要帮助你区分“浏览器里看到的输入响应”与“键盘硬件本身的绝对延迟”,避免把不同层级的结果混在一起理解。
不完全是。纯 Web 环境无法直接读取键盘开关导通、USB 发送和显示器像素变化的完整物理链路。本页更接近系统与浏览器层的输入处理延迟参考,而不是实验室级的硬件绝对延迟。
在现代浏览器和较轻负载的桌面环境里,平均值落在大约 5ms 到 15ms 往往已经比较优秀。如果长期高于 30ms,或者尖峰非常频繁,快节奏输入时更容易感觉到拖沓或不稳定。
因为手感依赖的是稳定性,而不是偶尔出现的一次漂亮低值。如果延迟忽高忽低,肌肉记忆更难建立,操作节奏也更容易被打断,所以标准差和曲线尖峰往往更值得关注。
可以优先从关闭不必要的后台负载、减少省电策略影响、关闭影响帧输出的垂直同步链路,以及优先使用有线或稳定 2.4G 连接这些方向去排查。
那就需要专业的物理测试设备,例如高速摄像机、示波器、外部触发控制板,或者成熟的商业输入延迟测试方案。浏览器页面本身做不到硬件实验室那种绝对定标。
只能非常粗略地猜一个大档位,不能准确判定真实回报率。因为这里混合了键盘回报率、传输方式、操作系统调度、浏览器主线程以及刷新率等因素。像 125Hz 约 8ms、250Hz 约 4ms、500Hz 约 2ms、1000Hz 约 1ms 这些只是理论轮询间隔,网页侧噪声往往足以淹没细分差异。