玩 PixVerse Game 时手感滞后，先别急着换设备、换网络。把一次按键或摇杆操作到屏幕上出现对应画面这一段，拆成输入采集、模型出帧、画面回显三个时间点分别打时间戳，就能看出等待集中在哪一段：是操作根本没被及时采集，是请求发出后要等很久才有可渲染的画面，还是画面已经在本地但没及时画出来。三段各自可测，结论才有落点。
输入到成帧的延迟可以拆成输入采集、模型出帧、画面回显三段独立计时。适用场景是在浏览器或客户端里玩 PixVerse Game 出现手感滞后、又分不清卡在哪一环；操作动作是在每次操作时打三个时间戳并写结构化日志；验证方式是日志行数与实际操作次数一致、同一配置下重复三轮以上观察波动；风险边界是页面主线程调度会影响计时精度，这些数字只适合横向比较同一环境下的不同配置，不宜当作绝对延迟指标对外引用。
把一次操作拆成输入、出帧、回显三个时间点
先把三个事件名定下来，后面所有记录都用同一套字段，避免前后对不上。
- 输入采集：事件名
input_capture，时间戳字段t_input。打点位置放在键盘、鼠标或触摸事件回调的第一行，早于任何业务分发逻辑。这样记录到的是“操作被页面接收到的时刻”，不包含后面排队的时间。 - 模型出帧：事件名
frame_ready，时间戳字段t_frame。打点位置放在游戏侧返回的画面数据已解码、可以交给渲染的位置，例如收到消息并解析完成的回调末尾。判断标准是“这一帧已经可画”，而不是“请求已发出”。 - 画面回显：事件名
paint_done，时间戳字段t_paint。打点位置放在提交渲染后的下一次绘制回调里，用requestAnimationFrame抢在浏览器完成这一帧后记录。这一段反映本地渲染和主线程占用。
三段拼起来，一次操作的总耗时近似为 t_paint - t_input，中间再切成 t_frame - t_input 和 t_paint - t_frame。如果输入事件本身触发得很稀，说明采集环节可疑；如果两个差值都正常但手感仍差，就要回头检查采样频率和网络往返，这已经超出这三段能覆盖的范围。
用本地计时脚本给每个阶段盖时间戳
下面的骨架只用浏览器自带的 performance.now() 和 requestAnimationFrame，不依赖任何官方接口或 SDK，把三个打点函数嵌到现有逻辑对应位置即可。
let tInput = 0;
let seq = 0;
// 1) 输入采集：事件回调第一行
function onInput(evt) {
tInput = performance.now();
forwardInput(evt); // 原有业务逻辑，不要改动顺序
}
// 2) 模型出帧：画面数据可画时
function onFrameReady(frame) {
const tFrame = performance.now();
draw(frame); // 提交渲染
requestAnimationFrame(() => {
const tPaint = performance.now();
console.log(JSON.stringify({
seq: ++seq,
t_input: +tInput.toFixed(2),
t_frame: +tFrame.toFixed(2),
t_paint: +tPaint.toFixed(2),
d_in_to_frame: +(tFrame - tInput).toFixed(2),
d_frame_to_paint: +(tPaint - tFrame).toFixed(2),
d_total: +(tPaint - tInput).toFixed(2)
}));
});
}替换项只有一处：draw(frame) 和 forwardInput(evt) 换成页面里真实的渲染与输入函数。放在浏览器控制台或页面内脚本执行都可以。验证方式是数日志行数：连续做 10 次同类操作，日志应当是 10 行；多出来说明某次操作触发了两次渲染，少了说明有操作没进到回调，这两种情况都要先修打点再谈延迟。
对比三段耗时找出最大的那一段
同一段操作下，看哪一列的差值最大，瓶颈就落到哪一类问题上。下表是判断方向，不是阈值标准，具体数值以自己环境里的记录为准。
| 最大的一段 | 典型现象 | 优先怀疑 | 先做的动作 |
|---|---|---|---|
输入到出帧 d_in_to_frame | 按下后要等一段时间画面才动，日志里 t_input 正常但 t_frame 明显靠后 | 请求往返、服务端排队、出帧等待 | 记录请求发出到响应的间隔，与 t_frame 对照看中间差在哪 |
出帧到回显 d_frame_to_paint | 数据早到了，屏幕却晚一拍才更新，或伴随掉帧 | 本地渲染开销、画布尺寸、主线程被其他任务占用 | 关掉后台标签页、降低画质档位后再打一遍点 |
| 三段都小但手感仍差 | 日志显示每段都不长，操作本身却像被吞掉 | 输入采样频率、事件绑定位置、焦点丢失 | 确认按键事件确实落在游戏容器上，而不是被外层元素拦截 |
只改一段再复测确认因果
同时改画质和网络，测出来变快也说不清是谁的功劳。每次只动一个变量，改完立刻按同样节奏做一轮同类型操作，然后原样回滚再测一轮。
- 单变量改动项举例：只调画质或分辨率档位；只换一种输入方式（键盘与触屏二选一）；只关闭占用主线程的后台页面；只把连接换成有线后不再动其他设置。
- 复测次数：每个配置下做 8 到 10 次同类操作，记录成一组，至少覆盖两组（改动前、改动后）。
- 记录格式建议：
#轮次 | 配置标签 | 操作类型 | d_in_to_frame | d_frame_to_paint | d_total，一行一次操作，配置标签写成能一眼认出的短名。
如果改动前后最大段换了一个，说明你动到了另一环，需要回到上一节重新对照。如果最大段没变、数值也没明显变化，这次改动对瓶颈无效，回滚即可。
重复三次以上看波动是否稳定
基线没有通用值，只有你自己环境里的基线：在同一配置下分三轮记录，每轮 8 到 10 次同类操作，每轮取中位数，避开单次尖峰的影响。判断写法可以这样落地：
- 三轮中位数落在相近区间，且最大的一段始终是同一段，按稳定瓶颈处理，直接针对那一段做优化。
- 三轮中位数相近，但某一轮出现个别很高的值，其余回到原区间，按偶发卡顿处理，先记下触发条件，例如首次加载、切回标签页、后台更新，而不是急着改配置。
- 三轮中位数本身就分散，且最大段来回跳，说明当前环境干扰太多，先固定一台设备、一个网络、一次只开一个页面，再重新取基线。
记录时保留原始日志行，不要只留中位数，否则后面无法判断波动是采样问题还是真实抖动。