Chrome Network Timing 各阶段怎么优化？
一次网络请求在 Chrome 里被拆成 6 个阶段，哪个阶段慢就优化哪个。绝大多数性能问题出在两个地方：TTFB 高（服务端处理慢或链路差）和 Content Download 高（响应体大或没压缩）。抓住这两个，性能问题解决大半。
逐阶段排查思路：
- Queueing（排队）：浏览器对同一域名限制并发连接数（HTTP/1.1 最多 6 个），超出的请求排队等。解法：升级 HTTP/2 多路复用，或域名分片把资源分散到 cdn1.example.com、cdn2.example.com 等子域名
- DNS Lookup：域名解析耗时，首次访问尤其明显。用
<link rel="dns-prefetch" href="//cdn.example.com">提前解析关键域名，浏览器在用到之前就完成 DNS 查询 - Initial connection / SSL：TCP 三次握手 + TLS 协商。开启 keep-alive 复用连接、减少第三方域名数量、升级 TLS 1.3（握手从 2-RTT 降到 1-RTT）
- Request sent：发送请求本身。Cookie 体积大是常见拖累——不需要每次携带的数据迁到 localStorage，精简 Cookie 到 4KB 以内
- Waiting (TTFB)：从发出请求到收到首字节的时间，这是最值得优化的阶段。
curl -w "TTFB: %{time_starttransfer}\n" -o /dev/null -s https://example.com先测出基线。服务端慢：查慢 SQL、加 Redis 缓存、升级服务器。网络慢：上 CDN 就近分发、检查是否有跨地域回源 - Content Download：下载响应体耗时。Gzip 或 Brotli 压缩（Brotli 比 Gzip 再小 15-25%）、CDN 分发、减少体积（懒加载图片、接口分页、去掉无用字段）
实战中不要逐个阶段优化，先用 Performance 面板抓一次完整加载，找到占比最大的 1-2 个阶段集中攻坚。
追问
TTFB 高怎么快速定界？
同机房 curl -w "DNS: %{time_namelookup} TCP: %{time_connect} TTFB: %{time_starttransfer} Total: %{time_total}\n" 一行命令拆出每个阶段耗时。TTFB 占比大 → 服务端问题，查慢查询和缓存命中率。DNS 或 TCP 占比大 → 网络问题，上 CDN 或切 DNS 服务商。
HTTP/2 多路复用为什么不能完全替代域名分片？
HTTP/2 在单连接上多路复用，解决了 HTTP/1.1 的队头阻塞问题。但它引入了新的瓶颈——单连接上任何一个流丢包，所有流都得等重传（TCP 层面的队头阻塞）。所以弱网环境下，多连接的 HTTP/1.1 + 域名分片反而可能更快。实际做法：HTTP/2 为主，极端场景保留域名分片做降级。
Service Worker 缓存对 Timing 有什么影响？
命中 Service Worker 缓存的请求跳过 DNS、TCP、TTFB 全部网络阶段，Timing 面板标记为 from ServiceWorker，响应时间通常是毫秒级。适合缓存静态资源和稳定的 API 响应，推荐 stale-while-revalidate 策略——先返缓存再后台更新，兼顾速度和新鲜度。
Core Web Vitals 和 Timing 面板有什么关系？
两者看的是不同层面。Timing 面板看单次请求的网络耗时，是"微观"视角。Core Web Vitals（LCP < 2.5s、INP < 200ms、CLS < 0.1）看用户体感，是"宏观"视角。TTFB 慢会拖累 LCP，资源体积大会影响 LCP 和 INP，但布局偏移（CLS）和 Timing 没有直接关系。两个维度配合诊断才完整。