这个页面给你的处理器一件重活，并告诉你它能不能一直干下去。这个说法比大多数 CPU 页面都保守，而且是刻意的。
这里的 worker 以浏览器允许的最快速度运行一个算术循环，并统计完成了多少次。这个数字取决于你的浏览器、它的版本、机器上还在做什么，以及引擎今天决定如何编译这个循环——所以它不是分数，也不该和别人的放在一起比。它真正的用处，是在你控制的负荷下，一分钟一分钟地把这台机器和它自己作比较。
开始运行后，吞吐会上升几秒，然后稳定下来。如果它能在那里保持五分钟，说明机器扛得住这个负荷。如果它下降一个台阶并停在下面，说明有什么在压低频率——热量、功耗墙，或者省电配置。等积累到足够的历史、确认不是在看某一秒的噪声之后，页面会告诉你。
没有温度，没有主频，没有风扇转速，没有处理器型号，也没有完全可信的核心数。在任何平台上，这些都不会暴露给网页；声称能读到的网站，只是在根据你的 User Agent 猜测。测试前唯一可得的事实是浏览器报告的线程数——而 Safari 和隐私模式连这个也会往下取整。想看温度，请在这个页面旁边运行本地监控软件。
全部线程是测试散热的设置：整块芯片发热，风扇必须响应，勉强够用的散热器几分钟内就会露馅。单线程则相反——芯片其余部分空闲，因此那个核心能冲到最高睿频并保持住。逐个线程运行也是找出某个核心异常、而其余核心正常的方法。
满载并不总是你需要复现的场景。一台全力运行时稳定、半载却卡顿的机器，问题是另一回事；而风扇曲线在稳定的 40% 下比全部一起狂转时更容易听清。滑块调节的是每个 worker 内部的占空比——每 100 毫秒中计算一部分时间，其余空闲——所以核心确实在承载负荷，只是不连续。
是的。网页做的任何事都无法把处理器推过它自身的极限：温度与功耗保护位于硬件和固件之中，在浏览器触及不到的层面，会在造成损坏之前很久就降频或直接关机。你应当预期的是机器发烫、风扇变吵，以及笔记本电脑电量快速下降。如果机器在测试中自行关机，那本身就是一个结论：散热或供电撑不住。
在真实负荷下听散热系统最快的方式，也能弄清一个从不转的风扇究竟是坏了，还是根本没被要求工作过。
前后运行同一个预设。以前三分钟就掉下去、现在能平稳五分钟的机器，是真的修好了。
在卖家面前跑二十分钟就够了。前五分钟就严重降频、或者自行关机的机器，散热问题会跟着一起买回家。
在把真正的工作交给新机器之前，先给所有线程加负载。没装好的散热器，或者撑不住的电源，只有在负载下才会露出问题。
只在负载下出现的故障追查起来非常痛苦。耐力预设可以按需复现这些条件，让你能观察发生了什么，而不是干等。
把强度稳定在 40% 或 50% 然后仔细听。在部分负载下忽高忽低来回摆动的风扇，或者在机器本该安静应对的负载下狂吼的风扇，指向的是曲线或传感器，而不是风扇本身。