![]()
做语音交互的工程师都懂一个数字: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面板?
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.