动态加载慢？5个隐性瓶颈提速300ms
|
线上报警那一刻，我正把冷掉的咖啡泼进绿植土里——那盆发财树叶子都黄半边了，跟我们接口耗时曲线一样蔫。运维老张在 Slack 甩了条红字：“/api/v2/dynamic-load 延迟破 800ms，P0。” 我扫了眼手机，屏幕亮了一下，是前天没回的产品消息：“这个加载态能不能再快点？H5 用户反馈卡顿。” 我顺手划掉，没回。 其实早该看出来。去年六月起，这个动态加载接口就总在凌晨三点飘红，不炸，但像指甲刮黑板——你听不出具体哪响，可就是睡不着。我原以为是缓存穿透，配了布隆过滤器；又以为是下游超时太宽，把所有依赖服务 timeout 全砍到 300ms；最后连灰度发布都改成按用户分桶做预热……结果呢？监控里那个毛刺还是稳稳蹲在 700–900ms 区间，不挪窝。
文章配图，仅供参考 直到上礼拜，前端小杨蹲我工位等复现：“王工，我加了 performance.mark，loading 起点到 DOM 挂载，差 300ms —— 这 300ms 是空白期，连 loading 图都不转。” 他键盘声很响，噼里啪啦敲 console.time() 的时候，窗外天黑了，灯自动亮起，惨白光打在监控大屏上，正好照着那个毛刺。 我说：“你查 JS 加载顺序没？” 我当时嘴一撇，心想又是个 JS 执行阻塞渲染的烂活儿。可拉了 V8 profiling 一看，主线程压根没在跑 JS：CPU 占用跌停，内存平稳，GC 也没动静。那一片灰，真就是空等。等啥？ 第一个揪出来的，是浏览器 prefetch 的一个废弃 ``。这玩意儿三年前加的，当时说“为后续接口预热”，结果后端早把 user-config 接口干掉了，现在返回 404，而 Chrome 对 404 prefetch 会傻等重试策略耗尽才放手——足足 267ms。运维老张后来骂了一句：“谁写的，留个壳不删还占 DNS 查询队列？” 我没接话，因为……这代码是我写的。 第二个是 JSON Schema 校验。前端调我们 `/dynamic-load` 返回的数据结构不稳定，他们怕崩，自己加了一层 ajv.validate。ajv 实例化要解析 schema 字符串，而 schema 文件有 1.2MB（别问为啥这么大，上古版本 UI 生成器吐的），JS 解析完得走两次 AST 遍历……小杨改用 `ajv.compileAsync` 重构后，那段死寂少了 83ms。我原以为是 schema 太大拖慢解析，结果抓包发现，是 `ajv.compileAsync` 默认带了个 `setTimeout(() => {}, 0)` 当微任务垫脚石——他们故意这么写的，就为了让校验不卡 render。真服气。 第三个最气人：我们文档里写“接口支持 gzip”，前端也就默认开了 accept-encoding，结果某次 nginx 配置更新漏掉了 brotli 支持开关，但没报错，只是默默退回 http1.1 + gzip。可关键来了——Chrome 在 http1.1 下对 gzip 解压是单线程同步做的，而那个响应体是压缩后 480KB。V8 里看不见它干活，它其实在 libz 里吭哧吭哧解码。工单系统又弹了条消息：“客户侧上报资源加载失败率上升 0.3%”，我扫了眼关掉。解压完了，才轮到 JS 执行。没人告诉过我，gzip 解压也能成瓶颈。 第四个……算了，不说了，反正你也踩过：`import('./feature-a.js').then()` 里头嵌了个 `fetch('/config.json')`，但 config.json 又被 CDN 缓存策略锁死了 10 分钟 max-age，且没开 stale-while-revalidate。于是每次发版后前 10 分钟，所有用户都得干等 config 下载完成才触发 dynamic-load 渲染逻辑。不是慢，是等。我们管这叫“优雅降级”，前端管这叫“优雅堵车”。 第五个最反常识：`document.readyState === 'interactive'` 这个状态，你以为 DOM 就绪了对吧？错。Chrome 会等所有 defer script 的 onl oad 回调跑完才切到 complete，而我们有个埋点 SDK 注入的 script 是 defer+async 混搭，它里头有个 `new Image().src = 'https://xxx?log=...'` ——这请求虽然小，但域名没预连，第一次 DNS+TCP 建连平均 180ms。它没 return，也没 reject，它就悬在那儿，等 socket 成立，才放行 next tick。页面卡在 interactive 里，不挂 loading，也不展内容，就……呼吸暂停式静音。 优胜劣汰这话，我现在信。不是指技术选型，是指这些破事能活到现在，纯粹因为没人真盯着它看。一出问题就加限流、加重试、加兜底，没人拆开看它到底在等谁。就像我们组去年招人，面了七个，六个都说“熟悉性能优化”，结果让现场 debug 一个空 waterfall 图，三个当场认怂，两个开始讲 LCP 和 CLS，剩下一个——是前端小杨，他直接问：“你们监控里有没有记录 requestStart 到 responseEnd 之间的非网络耗时？” 我愣了下，点头。他笑：“那先查那段灰，别查 JS。” 昨天我把这五个全压进一条灰度批次推了。监控里那个毛刺，今天早上没了。但我不敢说“彻底解决”，因为刚才 product 发来新消息：“iOS 下还有轻微卡顿，能不能查查 WKWebView 的 cookie 同步？” 我没回。刚泡了杯新咖啡，这次特意没放糖——太甜容易晕，得保持清醒等下一个毛刺冒头。现在我想看看 WebPageTest 里 resource timing 的 frame busy time 分布，但鼠标移到那个链接上，突然想起上周离职的老李说过：“别信 waterfall，信 devtools 的 event log，尤其留意‘Idle’之前那行粉色的小字。” 我点开，还在加载…… （编辑：站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
