这个AI面试官把850ms延迟砍到50ms

做语音交互的工程师都懂一个数字：400毫秒。超过这条线，对话就会卡壳；超过800毫秒，用户直接出戏。一位开发者在搭建AI编程面试平台时，实测到850毫秒的"死亡停顿"——AI说完话，候选人要等近一秒才能开口。他把这段调试过程公开后，技术社区炸了锅。

这不是网络慢，是时机错了。

问题出在WebSocket连接的打开时机。AI语音结束→打开麦克风连接→DNS解析→TCP三次握手→WebSocket协议升级，这套流程在常规网络环境下就要800-900毫秒。开发者形容："像面试官说完话突然发呆，然后才想起要听对方回答。"

他的解法堪称"偷时间"——利用TTS（文本转语音）播放的窗口期，提前把连接准备好。

850毫秒是怎么消失的

intervu.dev的对话循环原本有四步：用户说话→AI处理生成回复→TTS播放语音→打开麦克风等用户回应。前三步串行执行，第四步卡在连接开销上。

开发者实测发现，TTS播放时系统完全空闲。用户正在听，麦克风还没必要激活，但网络层可以动起来。他把这个洞察写成代码：TTS一开始播放，后台立即启动WebSocket连接；等AI说完，连接早已就绪，直接切到麦克风。

代码逻辑很直白。`onTTSPlaybackStart()`触发预加载，`onTTSPlaybackEnd()`检查连接状态：就绪就立即激活，没完成就走兜底逻辑。最坏情况400毫秒，是AI说话太短（1秒内）导致预加载没跑完。正常对话场景下，延迟压到50-80毫秒。

从"等连接"变成"等说话"，顺序一换，体验质变。

预加载不是新发明，是时机选择

浏览器里的预加载技术遍地都是：图片懒加载、DNS预解析、TCP预连接。但语音场景的预加载有个特殊约束——不能抢资源。TTS播放本身占带宽和CPU，如果预加载太激进，可能卡顿音频。

这位开发者的做法是"轻量预加载"：只开连接，不传数据。WebSocket的`onopen`回调标记就绪状态，实际音频流等TTS结束后再走。相当于提前占座，但不点菜。

社区讨论里有人提到类似思路：WebRTC的ICE候选收集也可以预做，减少首次通话延迟。还有人问为什么不用HTTP/2或WebTransport——WebSocket的浏览器兼容性仍是2024年的硬需求，尤其是企业内网环境。

50毫秒背后的取舍

优化后的数据很干净：常规连接50-80毫秒，短语音回退400毫秒。开发者没提的是，这个方案牺牲了极短交互的响应速度——如果AI只回一个"好"字，用户反而要等更久。

这是产品决策。面试场景里，AI回复通常不止一句话，预加载有足够时间完成。真遇到单字回复，400毫秒仍在可接受范围，不至于击穿体验底线。

代码里留了容错：`onerror`时把`micConnectionReady`标为false，自动降级到按需连接。没有为了优化而优化，把可靠性锁死。

技术债和体验债，他选了先还体验债。

这个案例被转发到多个技术论坛后，最热的评论是："原来我的语音助手卡顿不是因为OpenAI慢，是自家代码没调好。"另一条则很扎心："花了三个月优化大模型延迟，发现瓶颈在WebSocket握手。"

开发者最后补了一句：测量方式是从TTS结束事件触发，到后端收到首段音频数据。这个定义本身就有讲究——如果从前端麦克风激活算起，数字会更漂亮，但他选了用户无感的真实端到端延迟。

现在的问题是：当你的AI产品还在卷模型参数时，有没有先看过浏览器的Network面板？