不稳定的延迟比稳定的慢更难接受
别名: 延迟抖动 · 时延方差 · latency variance
概念解释
两次点击，一次 80 毫秒回来，一次 400 毫秒回来，比每次都 200 毫秒更难受。人讨厌的不是慢，是猜不准下一次要等多久。这个现象叫延迟抖动（latency jitter）：同一操作的时延方差大，主观成本高于均值更高但方差接近零的稳定慢。均值好看、尾巴很长的系统，体验上会输给一条略慢但每次都一样的系统。
机制
感知系统按最近几次间隔建立预期。下一次若落在预期里，等待被编成「正常」；若突然拉长，被编成「这一次坏了」。坏了的那一次会盖过前面九次正常——负面峰值比平均更记得住。稳定的慢可以变成节奏：人按 200 毫秒的拍子去点。抖动没有拍子，每次都要重新决定「还要不要再等、要不要再点」。决策本身有成本，比多等一百毫秒更烦。
游戏和音视频里这件事被测得很清楚：帧时间方差比平均帧时间更能预测「卡」的投诉。交互点击是同一条通路，只是采样率更低。
怎么研究
做两套延迟分布：一套均值低、方差大（例如 50–400 毫秒均匀），一套均值略高、方差接近零（例如固定 180 毫秒）。同一任务下比较偏好、完成时间和过早重试。
自变量：延迟的均值与方差（可正交设计）、是否有掉帧。 因变量：偏好（forced choice）、重试率、把系统描述为「卡」而非「慢」的比例。
报告时不要只给平均值。P95、P99 和方差才是抖动的可见部分。实验室若每次都清缓存或都走同一条热路径，会把现场才有的抖动测没。
边界
操作很少发生、每次都当新对话（一年开一次的报税页），人没有机会建立预期，抖动不比均值更伤——因为没有「下一次」。高风险提交（支付）里，人本来就会等确认，单次变长只要有等待反馈，不一定比抖动更糟；但同一次支付流程里按钮有时立刻有时卡住，仍会触发「是不是点上了」。实时控制（驾驶、手术、乐器）对抖动零容忍，稳定的慢在那些域里也不可接受，只是抖动先把系统判死刑。
怎么落地
- 性能预算同时卡住均值和尾部：P95 / P99 与 P50 一起过线，不要只报平均。
- 同一入口的重复操作（保存、发送、切换）优先削方差：缓存、连接复用、避免偶发的全量重算。
- 用户原话里的「卡」优先当抖动查，用户原话里的「慢」优先当均值查。
- 验证：连续点十次同一按钮，把十次耗时画出来。若高低差一截、人开始连点，抖动已经比均值更碍事。把十次都拉到略慢但几乎同一条线，连点应下降。