FPS 测试
持续运行 10 秒,期间会不断播放动画。
一款游戏或一个滚动页面,参数上看似流畅,用起来却可能一卡一卡的——平均 FPS 恰恰会掩盖那种让人觉得“卡”的丢帧。这款免费工具会在浏览器里直接进行 10 秒的帧时间测量,给出真正能解释体验好坏的数字:平均 FPS、1% 低帧率、帧时间百分位、卡顿帧数,以及推断出的显示器刷新率。
工作原理
- 关闭其他占用资源的程序. 暂停下载任务,关闭其他占用资源的标签页和应用,并让这个标签页保持在前台——后台负载会和测试正在测量的这些帧争抢资源。
- 点击开始,让它先热身. 最开始的几帧会被自动丢弃——刚启动的动画还在稳定下来,这几帧并不具有代表性。
- 观察进度条和帧时间色带. 来回扫动的进度条和下方的色带就是被计时的对象本身——出现明显跳动或尖峰,说明是真实的丢帧,而不是显示故障。
- 耐心等待 10 秒测量完成. 测试固定运行 10 秒,这样 1% 低帧率和各项百分位数才有足够多的帧作为支撑,得出稳定的统计结果,而不是恰好碰上的一个好运或倒霉的瞬间。
- 查看平均值、1% 低帧率和卡顿次数. 平均值是最显眼的数字,但 1% 低帧率和卡顿次数往往才更诚实地反映了实际体验。
- 对照推断出的刷新率来看结果. 结果的评级是相对于显示器推断出的上限而言的——58fps 在 60Hz 屏幕上算优秀,放到 144Hz 屏幕上就只是平庸水平。
本测试如何测量你的帧率
浏览器绘制的每一帧都会经过 requestAnimationFrame——这是一个浏览器 API,会在下一次重绘之前调用你的代码,并附带一个精确的时间戳。本测试计算相邻时间戳之间的间隔,这个间隔就是一帧真正、物理意义上到达屏幕所用的时间,比单纯数一数每秒出现了多少帧要诚实得多。
- 最开始的几帧会被丢弃——刚挂载的动画、纹理上传和布局稳定过程,都会让早期的帧不具代表性。
- 画布上来回扫动的进度条,和下方的帧时间色带,都是在同一个被计时的循环内部绘制出来的——你看到的就是被测量的东西本身,而不是另外单独跑的一段动画。
- 每次运行固定持续 10 秒,时间足够长,一次偶发的卡顿才能作为真实的统计数据体现出来,而不会被噪声淹没,也不会因样本太短而被过度放大。
平均 FPS、1% 低帧率与帧时间:每个数字分别代表什么
单一的平均值掩盖的东西比它揭示的更多。一次运行前九秒丝般顺滑、最后一秒卡死,平均下来依然能得出一个不错的数字——这正是本测试要给出四个不同数字,而不是一个数字的原因。
- 平均 FPS:总帧数除以总时间。容易读懂,但也容易被“钻空子”——大部分流畅的帧会掩盖少数很差的帧。
- 1% 低帧率:只取运行中最慢的 1% 帧,计算它们的平均帧率。这比平均值更接近你实际感受到的“卡顿”。
- 帧时间百分位(p50/p95/p99):典型一帧耗时多久,以及只有最差的 5% 或 1% 的帧才会达到的耗时——两者之间的差距,直接反映了流畅程度的稳定性。
- 卡顿帧数:有多少帧的耗时明显超出了显示器的帧预算——也就是人眼真的能察觉到跳帧的那些帧。
哪些原因会造成平均 FPS 掩盖的卡顿
如果平均值完全正常,但 1% 低帧率偏低,或卡顿帧数偏高,几乎总是说明有某种间歇性的干扰,而不是硬件性能到了上限。
- 后台标签页和应用抢占 CPU/GPU 资源,尤其是那些自己在做渲染或视频解码的程序。
- 浏览器关闭了硬件加速,导致合成工作全部压到 CPU 上。
- 显卡驱动过旧或版本不匹配,尤其是在 Windows 更新之后。
- 笔记本电脑出现降频——如果测试或游戏运行得越久卡顿越明显,休息一下又恢复正常,这是很典型的温度信号。
- 省电模式限制了 CPU/GPU 频率,笔记本用电池供电时很常见。
- 浏览器扩展向每个页面注入脚本,给每一帧都增加了一点实实在在的开销。
为什么浏览器读不到刷新率(以及“推断”是什么意思)
没有任何 Web API 能直接读取显示器的刷新率——并不存在可以调用的 navigator.refreshRate。这款工具的做法是从绘制节奏本身来推断刷新率:当帧稳定到达时,大多数帧会紧密聚集在同一个时间间隔附近,而这个间隔几乎可以肯定就是显示器真实的帧预算。
- 置信度高:绝大多数帧都落在一个明确、狭窄的时间区间内,且该区间对应常见的刷新率(60/75/90/100/120/144/165/240Hz)。
- 置信度中等或低:帧比较分散,要么是因为有什么因素干扰了测试,要么是因为显示器本来就没有维持在某个恒定的刷新率上。
- 结果显示“无法确定”本身也是一种信息——通常意味着测试被打断了,或者你的屏幕使用了自适应同步(见下文)。
自适应同步:G-Sync、FreeSync 与 VRR
可变刷新率(VRR)——也就是 NVIDIA G-Sync、AMD FreeSync,或者笼统地说的“自适应同步”——会刻意让显示器的刷新间隔随显卡的输出变化,而不是固定在一个数值上。这是一项真正的功能,不是缺陷:它的设计初衷就是消除显卡输出和显示器固定节奏之间的错位,让不稳定的帧率感觉更顺滑。
在支持 VRR 的屏幕上,本测试推断出的刷新率经常会——而且是正确地——显示为低置信度,因为根本不存在一个可以锁定的固定间隔,毕竟你的显示器本来就没有维持一个。这是测试在正常工作,不是故障。上面的帧时间统计数据(平均值、1% 低帧率、卡顿帧数)不受影响,依然有参考意义。
常见解决办法:硬件加速、线材与刷新率设置
- Windows:设置 → 系统 → 显示 → 高级显示设置,确认刷新率确实设成了屏幕的最大值——新装驱动或换一根新线,有时会悄悄把它重置回 60Hz。
- 带 ProMotion(120Hz)的 macOS:在系统设置 → 显示器 中检查刷新率是否设为动态/高刷新选项,而不是固定的 60Hz。
- 外接显示器达不到标称刷新率:线材和接口很关键——高分辨率下的高刷新率需要 DisplayPort,或者版本足够新的 HDMI,而不是随包装盒附送的随便一根线。
- 浏览器内:确认浏览器设置中已开启硬件加速,如果卡顿依然存在,可以逐个禁用扩展排查。
- 笔记本电脑:测试前先插上电源,并把电源计划设为“最佳性能”,因为省电模式是一种常见但不易察觉的限制。
本测试不是什么
这是一款帧时间诊断工具,不是显卡跑分工具,也不是专用的刷新率测量仪。它刻意不渲染沉重的 3D 场景去压榨显卡换取一个可比较的分数,也不会宣称能像专用硬件工具那样读出屏幕的精确刷新率——它是从绘制节奏推断出来的,并且全程如实标注为“推断值”。
常见问题
为什么每次运行测试,我的 FPS 数字都不一样?
每次运行结果有些许波动是正常的——后台进程、设备温度、当时打开了哪些程序,这些每次都会略有不同。如果波动很大,通常说明有间歇性的因素在争抢资源,可以试着关闭其他标签页和应用后再测一次。
多高的 FPS 算好?
这取决于你的显示器,而不是一个绝对数字——58fps 在 60Hz 屏幕上算优秀,放到 144Hz 屏幕上就只是平庸,这也是为什么本工具是相对于推断出的刷新率来评级,而不是用一个固定的门槛。
为什么我的 60Hz 屏幕测出来是 58 FPS,而不是正好 60?
比理论最大值低那么几帧完全正常——没有任何东西能以数学意义上完美、恒定不变的间隔来绘制。真正说明有问题的是 1% 低帧率和卡顿帧数,而不是平均值附近的小幅波动。
“1% 低帧率”是什么?为什么它比平均 FPS 更重要?
它是这次运行中最慢的 1% 帧的平均帧率。如果平均值很高但 1% 低帧率很低,说明大部分时间都很流畅,但确实发生过一次能被察觉到的明显卡顿——这正是单一平均值会掩盖的东西。
这个测试能测出我显卡的真实性能吗?
不能直接测出——它测量的是浏览器绘制一个轻量 canvas 动画的稳定程度,主要反映的是显示管线和当时的资源争抢情况,而不是显卡在高负载 3D 渲染下的性能上限。专用的显卡跑分工具是另一种更“重”的工具。
为什么浏览器不能直接告诉我显示器的精确刷新率?
因为没有任何 Web API 会暴露这个数值。本工具是根据帧实际到达的情况来推断的,所以结果始终标注为附带置信度的推断值,而不是直接从硬件读取的数据。
为什么切换标签页或最小化窗口后,我的 FPS 会下降?
浏览器会限制后台标签页以节省电量和 CPU 资源——这也是为什么如果测试过程中标签页被切到后台,本测试会中止并提示重新开始:来自后台标签页的结果毫无意义。
这个测试会耗电或让设备发热吗?
不会比其他任何一段 10 秒的动画更耗电。它绘制的是一个简单的 2D canvas,不是沉重的 3D 场景,而且测量窗口结束后会自动停止。
为什么同一台电脑上,Chrome、Firefox 和 Safari 测出的结果不一样?
每个浏览器都有自己的合成器和调度机制,扩展、硬件加速的默认设置、更新节奏也各不相同——出现一定差异是正常的,不代表哪个浏览器出了问题。
卡顿(jank)到底是什么?
指某一帧到达所用的时间明显超出了显示器的帧预算——长到人眼能察觉出这是一次跳帧或卡顿,而不是流畅的运动。
本测试完全在你的设备本地运行——它只是绘制一个 canvas 动画,并对你自己浏览器的帧进行计时。任何帧数据、计时信息或结果都不会被上传、传输或存储到任何地方。