首次输入延迟与稳态延迟需分别测量
别名: FID · 冷热延迟 · first input delay
概念解释
同一次会话里，第一次点击往往比第五次慢。主线程还在跑启动脚本、字体在下载、JIT 还没热，第一次输入要在拥堵里插队。首次输入延迟（first-input delay）测的是这场拥堵；稳态延迟（steady-state latency）测的是拥堵过去之后，每一次跟手还剩多少。两笔账不能合成一个「平均响应」。平均会把唯一一次很慢的第一下稀释掉，而第一下正是人用来给产品定调的那一下。
机制
启动是一段非平稳过程。事件循环被解析、布局、水合、权限弹窗占用，输入事件排队。第一下的延迟里，真正的输入处理只占一小截，大部分是「轮到你」之前的等待。稳态之后，这些一次性工作消失，剩下的才是架构里固有的跟手成本。把两段混在一个直方图里，优化者会去削稳态的尾巴，却看不见启动窗口里那一次决定性的钝。
人的评价也不对称。第一下慢，会定下「这个应用沉」的先验；后面再快，先验要很多试次才能改。所以首次输入不只是一个技术峰值，它是体验的锚点。
怎么研究
按时间分段采样：会话前 3 秒、第 3–10 秒、10 秒之后，分别报告输入到像素的延迟分布。网页里的 First Input Delay / Interaction to Next Paint 就是这种分段的工程近似，但实验室仍应在装置上直接打时间戳。
自变量：是否包含启动期、是否预热、输入发生在第几次。 因变量：P50 / P95 延迟、分段后的分布形状、主观「第一下」与「用熟了」评分是否分离。
只在应用「准备好了」之后才开始测的基准，会系统性低估用户真实碰到的第一下。现场日志若丢掉启动期，结论会偏乐观。
边界
常驻前台、已经热过的工具（一直开着的编辑器）几乎没有首次输入问题，稳态才是主战场。广告 SDK、自动播放视频会把「启动期」拉得很长，首次输入窗口可能持续几十秒，分段边界要按产品改。游戏在 loading 之后才开放输入，loading 本身不是首次输入延迟，不要把加载时长写进这一指标。自动化测试若每次都先点一遍「唤醒」，测到的全是稳态。
怎么落地
- 指标拆成两列：冷启动后的第一次输入，以及互动一分钟后的连续输入。两列都过线才算过。
- 启动期尽量不挡住输入：骨架可点、首屏先可滚，把非关键脚本推迟到第一次交互之后。
- 实验室不要在点了三下「热身」之后才开始计时。
- 验证：卸载后重装（或清缓存）打开，立刻点主按钮，记下第一下。再用一分钟后的第十下对比。只报后面那一下的产品，会把用户每天真正碰到的第一下藏起来。