前端Network性能优化场景解析

|-------------------------|----------------------------------------------------------|-----------------------------------------------------------------------------|-------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 调试场景 | 核心列（必看） | 辅助列（补充） | 场景说明 | 实操技巧 |
| 1. 定位慢请求（整体耗时久） | Time（总耗时）Name（资源名称）Status（状态码） | Size（资源大小）Domain（域名） | 快速找出页面中加载时间最长的资源，判断是 "资源本身大" 还是 "请求处理慢" | 1. 按「Time」列降序排序，耗时 Top5 的请求优先排查； 2. 若 Status=200 但 Time>1s：看 Size 是否过大（需压缩资源），或 Domain 是否为跨域慢域名（考虑 CDN 加速）； 3.若 Status=4xx/5xx：优先解决接口错误（不是性能问题，是功能错误） |
| 2. 分析资源加载瓶颈（细分耗时阶段） | Waterfall（瀑布流） Name（资源名称） Time（总耗时） | Stalled（阻塞） DNS Lookup（DNS 解析） Waiting (TTFB)（首字节等待） Content Download（内容下载） | 定位慢请求的具体瓶颈（是阻塞、DNS 解析、服务器响应还是下载慢） | 1. 打开「Waterfall」列的细分列（右键 Waterfall→勾选对应细分项）； 2. 若 Stalled 时间长：检查是否同一域名并发请求数超限制（HTTP/1.1 默认 6 个），可拆分域名或升级 HTTP/2； 3. 若 DNS Lookup 长：优化域名解析（如使用 DNS 预解析-prefetch">； 4.若 Waiting (TTFB) 长：服务器处理慢，需后端优化接口逻辑； 若 Content Download 长：资源体积大，需压缩（图片 / WebP、JS/CSS 压缩）或懒加载 |
| 3. 排查缓存未命中问题 | Size（资源大小） Name（资源名称）Protocol（协议版本） | Cache-Control（响应头缓存策略） Age（缓存存活时间） | 确认资源是否命中本地缓存（磁盘 / 内存缓存），避免重复加载 | 1. 筛选「Size」列中不含(disk cache)/(memory cache)的请求（未命中缓存）； 2.查看辅助列「Cache-Control」：若值为no-cache/no-store（禁止缓存），需调整后端缓存策略； 3.若 Protocol=http/1.1 且频繁未命中：考虑升级 http/2，或优化缓存过期时间（如静态资源设 1 年缓存 + 指纹） |
| 4. 分析跨域请求性能 | Domain（域名）、Time（总耗时）、Protocol（协议版本） | Remote Address（远程地址） SSL（SSL 握手时间） | 跨域请求（不同 Domain）易因 DNS 解析、SSL 握手、CORS 预检导致耗时增加 | 1. 筛选「Domain」列，分离出非主域名的跨域请求； 2. 若 SSL 时间长：检查 HTTPS 证书是否高效（如使用 TLS1.3），或跨域域名是否在同一 CDN； 3. 若有 OPTIONS 预检请求（Method=OPTIONS）：后端配置 CORS 预检缓存（Access-Control-Max-Age），减少预检次数 |
| 5. 优化资源加载顺序（优先级问题） | Priority（优先级）Waterfall（瀑布流）Name（资源名称） | Initiator（发起者）Type（资源类型） | 确保核心资源（脚本、样式）优先加载，非核心资源（图片、广告）不阻塞渲染 | 1. 按「Priority」列排序，查看高优先级（High）资源是否在瀑布流最前面加载； 2.若低优先级资源（Low）阻塞核心资源：调整加载顺序（如脚本放 ``defer`，图片懒加载）； 3. 若 Initiator 为非核心脚本触发的高优先级请求：优化脚本执行时机，避免过早触发非必要请求 |
| 6. 排查请求头 / 响应头过大问题 | Request Headers Size（请求头大小） Response Headers Size（响应头大小） | Status（状态码）、Url（完整 URL） | 部分服务器限制请求头大小（如 NGINX 默认 4KB），过大可能导致 400 错误或性能下降 | 1. 勾选显示「Request Headers Size」「Response Headers Size」列； 2.若请求头大小 > 4KB：清理冗余 Cookie、减少自定义请求头，或调整服务器配置； 3. 若响应头过大：移除不必要的响应头（如 Server、X-Powered-By 等冗余字段） |
| 7. 分析并发请求限制问题 | Waterfall（瀑布流）、Domain（域名）、Stalled（阻塞时间） | Protocol（协议版本）、Name（资源名称） | HTTP/1.1 同一域名仅支持 6 个并发请求，超出会排队（Stalled 时间长） | 1.查看 Waterfall 列中是否有多个同一 Domain 的请求 "排队"（前一个请求完成后下一个才开始）； 2. 若有排队：拆分静态资源到多个子域名（如img1.xxx.com、img2.xxx.com），或升级到 HTTP/2（无并发限制）； 3. 按 Domain 分组（Network 面板顶部「Group by domain」），更直观查看各域名的并发情况 |
| 8. 定位大体积资源（优化加载速度） | Size（资源大小）、Body Size（响应体大小）、Type（资源类型） | Name（资源名称）、Content Download（内容下载时间） | 大体积资源（如未压缩图片、大型 JS 包）是加载慢的主要原因，需针对性压缩 | 1. 按「Size」列降序排序，筛选 Size>500KB 的资源； 2.若 Type=img：检查是否使用 WebP/AVIF 格式，是否压缩分辨率；. 3.若 Type=script/css：检查是否拆分代码（Code Splitting）、是否开启 Tree-Shaking，或使用 Gzip/Brotli 压缩； 4. Body Size 接近 Size：说明响应体是主要体积，重点优化资源本身 |