性能基准：我们能跑多快
棋盘首屏、落子响应、AI 思考耗时：把 YiBoard 在一台中端手机和一台旧笔记本上的实测数字摊开讲，包括还没做好的那部分。
一个浏览器棋类站的性能基准，说到底就是三个数字：棋盘多快出现、落子多快生效、引擎思考多久。我们在一台 2021 年的中端安卓手机和一台 2017 年的笔记本上测这三个数字，因为这两台机器基本覆盖了真正会来玩的人。
把这些数字公开是一种承诺。以后哪个版本让其中一项变差了，那就是一个必须解释的回退，不能悄悄吞掉。
我们测什么，在什么机器上测
- 棋盘首屏：从发起导航到网格和坐标可见、可点的时间。
- 落子往返：从手指或鼠标动作到棋子出现的时间，线上对局还包含服务器校验。
- 引擎思考耗时：默认 500 ms 预算下，AI 返回一步棋的墙钟时间。
- 静置开销：棋盘开着但什么都没发生时，CPU 和电量的消耗。
手机是三年前的骁龙 7 系设备，跑 Chrome。笔记本是双核 i5 加核显，跑 Firefox。两边都在限速网络下测，因为真实访客很少待在干净的实验室网络里。
当前版本的数字
- 棋盘首屏：手机 1.1 秒，笔记本 0.8 秒，缓存为空时测量。
- 离线落子往返：低于 16 毫秒，也就是一帧动画。
- 在线落子往返：手机在 4G 下 90 到 140 毫秒，笔记本在家用宽带下 60 到 90 毫秒。
- 引擎思考耗时：默认预算下 480 到 520 毫秒，超时就退回更浅的搜索，不会阻塞。
离线落子那个数字比看上去更重要。一个要花两帧才响应的棋盘，用起来就是卡，而这种卡没法在评测里解释过去。
时间到底花在哪
首屏的大头不在棋盘本身，而在 CSS、字体和框架包先到达、再被解析。棋盘不过是一次几百条线的画布绘制，等 JavaScript 跑起来之后很便宜。
- 冷启动首屏里大约一半是共享包的网络与解析时间。
- 大约五分之一是字体加载，这也是我们先用系统字体栈的原因。
- 剩下的是水合与第一次画布绘制。
这个分布解释了为什么到目前为止最大的收益来自少发 JavaScript，而不是优化绘制代码。相关工作在 性能专项，移动端特有的修正在 移动端优化。
我们还不满意的部分
观战视图比下棋慢。多渲染一块棋盘加上棋谱列表，会把手机在快棋中压到每秒 45 帧左右，评论面板打开时更差。我们正在把这块改成按需渲染，而不是每步都渲染。
棋谱拖动是小一号的同类问题。在 2017 年那台笔记本上，把滑块拖过一局百步的棋会掉帧。两项都列在 观战与解说规划 里。
怎么保证数字不作假
- 每次构建都在 CI 里跑棋盘首屏和落子往返检查，超过阈值就算构建失败。
- 引擎预算是硬上限。搜索跑不完就返回目前找到的最好一步，而不是延长时间。
- 我们在自己拥有的硬件上测，不用模拟器，因为模拟器的时序会把一切都显得更好。
只写在博客里的基准一个月就过期了。有用的版本是每次提交都跑、变差就拦住合并的那个。
FAQ
YiBoard 的 AI 和服务器端引擎比，速度怎么样？
它在你的浏览器里跑，思考预算 500 毫秒，没有网络往返也没有排队。服务器端引擎可以搜得更深，但会加上延迟和对连接的依赖。这个取舍写在 浏览器里的真引擎。
棋盘能跑满 60 帧吗？
近五年的笔记本可以。三年前的中端手机在正常对局中能守住 60 帧，观战视图会掉到 40 多帧，这是已知的缺口。
为什么数字看着挺好，玩起来还是慢？
通常是连接的问题，不是设备的问题。线上落子包含服务器校验，信号弱就表现为点击和棋子出现之间有延迟。跟 AI 下就没有这一跳，参见 浏览器里的真引擎。
每次发布都会更新这些数字吗？
CI 里的阈值在仓库中是公开的，下一轮工作的安排记在 性能专项。当某个版本让其中一项数字发生移动时，我们会重述这些头条数字。
Related
- 性能优化：让棋盘更丝滑
2026-10-19
- Chess.com 做对了什么：平台生意模型拆解
2026-09-09
- 网页版 vs 桌面版：体验对比
2026-09-06