第一步：定位延迟瓶颈——从浏览器Timing到端到端Trace
任何延迟优化都必须从“测量”开始，否则只会盲目猜测。浏览器提供了Performance API，开发者可以通过`performance.getEntriesByType('resource')`获取每个静态资源的DNS查询、TCP连接、TLS握手、TTFB（首字节时间）以及内容下载耗时。例如，当TTFB数值远高于其他指标时，瓶颈大概率在服务端处理或网络路由；而如果“contentDownload”阶段耗时过长，则可能是带宽不足或资源体积过大。对于后端链路，则可以用OpenTelemetry或Jaeger这类分布式追踪工具，记录一次请求在网关、微服务、数据库之间的实际耗时。只有将前后端时间数据串联起来，才能准确判断延迟从哪一环开始积累，避免把时间浪费在错误的优化方向上。建议在项目初始化时就埋点并记录基线数据，后续每次改动都通过与基线对比来验证是否真正生效。
第二步：缩短网络路径——CDN加速与HTTP/2连接复用
物理距离和数据传输往返次数是网络延迟的重要来源。将静态资源部署到CDN边缘节点，可以让用户从最近的机房获取文件，大幅缩小地理位置带来的RTT（往返时间）。同时，CDN还能在边缘完成压缩和HTTP缓存，进一步降低源站压力。另一方面，协议层面的优化同样关键：HTTP/2的多路复用允许一个TCP连接并行传输多个请求，彻底解决了HTTP/1.x时代的队头阻塞问题；而TLS 1.3将握手压缩到一次往返，配合Session Resumption甚至可以实现零往返恢复。建议在HTML中为关键域名添加`dns-prefetch`和`preconnect`，提前解析DNS并建立连接，让后续请求发送时无需等待。如果站点支持HTTPS，还应当启用HSTS和OCSP Stapling，减少浏览器首次访问时的校验延迟。这些手段叠加起来，往往能直接削减一半以上的网络往返次数。
第三步：减少数据体积——Brotli压缩与分层缓存策略
同一网络条件下，传输数据越少，响应速度自然越快。现代浏览器大多支持Brotli压缩算法，它的压缩率比Gzip高出15%~20%，适用于HTML、CSS、JavaScript等文本资源。服务器只需在`Content-Encoding`中返回`br`即可，同时要针对图片使用WebP或AVIF格式，相比传统JPEG/PNG体积可减少30%~50%。除了压缩，缓存策略是降低重复请求延迟最有效的手段：通过`Cache-Control`设置资源新鲜度，配合`ETag`做条件请求，可以避免不必要的重新下载。对动态页面，可在数据库查询层加缓存，把热点数据放入Redis；对渲染结果，则可采用SSR静态化或边缘函数缓存。合理的分层缓存结构，让大多数请求在到达源站前就直接命中，用户感知到的响应时间会大幅缩短。需要特别注意的是，缓存键要包含用户身份与业务版本信息，避免出现数据错乱。
验证与回归——构建持续监控与延迟预算
优化不是一次性的工作，而是需要持续维护的工程能力。引入真实用户监控（RUM），收集不同网络环境下的LCP（最大内容绘制）、TTFB、FCP等核心指标，并将数据按地区、运营商、设备类型分类聚合，才能发现隐藏的性能问题。更重要的是，团队需要制定“延迟预算”（Performance Budget），例如规定首页LCP小于2.5秒、TTFB小于800毫秒，然后在CI/CD流程中接入Lighthouse或WebPageTest，当某项指标超出预算时阻止合并或发布。这样一来，任何代码改动都不会无意识拖慢响应速度。同时，定期使用A/B测试对比优化前后的关键业务转化率，验证性能提升与商业指标的关联。最后，将延迟监控面板接入告警系统，当某个地区的响应时间异常升高时，第一时间定位到CDN回源或服务器扩容。通过这种闭环迭代，延迟优化才能从“临时救火”变成“长期机制”。
