JS `Network` 面板高阶：`waterfall` 图、请求优先级、HTTP/2 推送分析

各位攻城狮，晚上好！我是你们今晚的“网速救星”——一位致力于把玄学网络性能调优变成科学的苦逼前端。今天咱们不聊框架源码，也不谈架构设计，就来抠一抠 Chrome DevTools 里的 Network 面板，特别是那几个高级功能：waterfall 图、请求优先级、HTTP/2 推送分析。别怕，我会尽量把这些听起来高大上的东西，用最接地气的方式掰开了揉碎了讲给你们听。

一、Waterfall 图：网络请求的“时间线”

首先，咱们得搞明白 Waterfall 图是个啥。简单来说，它就是你页面上所有网络请求的“时间线”，清晰地展示了每个请求从发起到完成的整个过程，包括 DNS 查询、建立连接、发送请求、等待响应、接收数据等等。

1.1 理解 Waterfall 图的组成部分

Waterfall 图中的每一行代表一个网络请求，每一条彩色的“柱状图”则代表了请求生命周期中的各个阶段。这些阶段通常包括：

• Queued (排队中): 请求被浏览器排队等待发送。可能的原因是：
  • 浏览器对同一域名的并发连接数有限制（通常是 6 个，HTTP/1.1 的限制）。
  • 请求被延迟以节省资源（例如，优先级较低的请求）。
  • 浏览器正在等待可用的 TCP 连接。
• Stalled (停滞): 请求在真正发送之前，因各种原因被延迟。这可能是请求被排队后等待的时间。
• DNS Lookup (DNS 查询): 浏览器查找域名对应的 IP 地址所花费的时间。
• Initial connection (初始连接)/Connecting (连接中): 浏览器与服务器建立 TCP 连接所花费的时间。
• SSL (TLS) Negotiation (SSL 协商): 如果使用 HTTPS，这是浏览器与服务器协商加密连接所花费的时间。
• Sending (发送请求): 浏览器发送 HTTP 请求到服务器所花费的时间。
• Waiting (TTFB) (等待服务器响应，TTFB): Time To First Byte，从发送请求到接收到服务器第一个字节的时间。这是衡量服务器响应速度的重要指标。
• Content Download (内容下载): 浏览器下载响应数据所花费的时间。

1.2 实例分析：一个简单的请求

假设我们有一个简单的页面，加载一个图片 image.jpg，Waterfall 图可能如下：

| Request        | Queued | Stalled | DNS Lookup | Connecting | SSL | Sending | Waiting (TTFB) | Content Download |
|----------------|--------|---------|------------|------------|-----|---------|----------------|------------------|
| image.jpg      |  0ms   |   2ms   |     5ms    |     15ms   | 20ms|   1ms   |       50ms      |        100ms     |

• Queued: 请求排队 0ms。
• Stalled: 停滞 2ms。
• DNS Lookup: DNS 查询花费了 5ms。
• Connecting: 建立 TCP 连接花费了 15ms。
• SSL (TLS) Negotiation: SSL 协商花费了 20ms。
• Sending: 发送请求只用了 1ms。
• Waiting (TTFB): 服务器响应花了 50ms。
• Content Download: 下载图片数据花了 100ms。

通过这个简单的例子，我们可以看到每个阶段的时间消耗，并找到优化的方向。比如，如果 DNS Lookup 时间过长，可以考虑使用 DNS 预解析；如果 TTFB 过长，则需要优化服务器性能。

1.3 利用 Waterfall 图发现性能瓶颈

Waterfall 图最强大的地方在于，它可以帮助我们快速定位性能瓶颈。例如：

• 大量的请求排队： 表明浏览器对同一域名的并发连接数已经达到上限。解决方案包括：
  • 域名分片 (Domain Sharding): 将资源分散到多个域名下，增加并发连接数。但要小心，过多的域名会增加 DNS 查询的开销。
  • 资源合并 (Resource Bundling): 将多个小文件合并成一个大文件，减少请求数量。
• TTFB 过长： 表明服务器响应速度慢。解决方案包括：
  • 优化后端代码和数据库查询。
  • 使用 CDN (Content Delivery Network)，将资源缓存到离用户更近的服务器上。
  • 启用服务器端的缓存。
• Content Download 时间过长： 表明资源文件太大。解决方案包括：
  • 压缩资源文件 (Gzip, Brotli)。
  • 优化图片 (压缩、使用更高效的格式)。
  • 代码分割 (Code Splitting)，只加载当前页面需要的代码。

二、请求优先级：告诉浏览器“谁先上”

浏览器在加载资源时，会根据一定的优先级规则来决定哪些资源先加载。默认情况下，浏览器会根据资源的类型和在 HTML 中的位置来分配优先级。例如，CSS 通常比图片优先级高，因为 CSS 会影响页面的渲染，而图片只是内容。

2.1 浏览器默认的优先级规则

一般来说，浏览器会遵循以下优先级规则（从高到低）：

1. HTML
2. CSS
3. JavaScript (特别是阻塞渲染的脚本)
4. 字体
5. 图片
6. 其他资源 (例如，异步加载的脚本)

2.2 手动调整请求优先级：fetchpriority 属性

HTML5 引入了 fetchpriority 属性，允许我们手动调整资源的优先级。这个属性可以应用于 <img>、<script>、<link> 标签，有三个可选值：

• high: 高优先级，告诉浏览器尽快加载这个资源。
• low: 低优先级，告诉浏览器稍后加载这个资源。
• auto: 默认值，浏览器根据自己的规则来分配优先级。

示例：

<img src="important-image.jpg" fetchpriority="high" alt="重要图片">
<script src="analytics.js" fetchpriority="low"></script>

在这个例子中，important-image.jpg 会被赋予高优先级，而 analytics.js 会被赋予低优先级。

2.3 使用场景和注意事项

• 首屏内容优化： 将首屏需要的图片和 CSS 设置为 fetchpriority="high"，确保它们尽快加载，提升用户体验。
• 非关键资源延迟加载： 将非关键的图片、脚本和字体设置为 fetchpriority="low"，避免阻塞首屏渲染。
• 避免过度使用： 不要滥用 fetchpriority 属性，否则可能会适得其反。浏览器通常有自己的优化策略，过度干预可能会破坏这些策略。
• 兼容性： fetchpriority 属性的兼容性还在不断完善中，需要注意浏览器的支持情况。

2.4 在 Network 面板中查看请求优先级

在 Chrome DevTools 的 Network 面板中，你可以看到每个请求的优先级。默认情况下，这个列是隐藏的，你需要右键点击表格头部，选择 Priority 来显示它。

你可以根据实际情况，调整资源的优先级，并观察 Waterfall 图的变化，从而找到最佳的性能优化方案。

三、HTTP/2 推送分析：服务器主动出击

HTTP/2 引入了一个重要的特性：服务器推送 (Server Push)。它允许服务器在客户端请求之前，主动将客户端可能需要的资源发送给客户端。这可以减少客户端发起请求的次数，从而提高页面加载速度。

3.1 HTTP/2 推送的工作原理

当客户端请求一个资源 (例如，HTML 文件) 时，服务器可以分析这个请求，并判断客户端接下来可能需要哪些资源 (例如，CSS 文件、JavaScript 文件、图片)。然后，服务器可以在响应 HTML 文件的同时，将这些资源也“推送”给客户端。

客户端收到推送的资源后，会将它们缓存起来。当客户端真正需要这些资源时，可以直接从缓存中获取，而不需要再次发起请求。

3.2 如何开启 HTTP/2 推送

HTTP/2 推送需要在服务器端进行配置。具体的配置方式取决于你使用的服务器软件 (例如，Nginx, Apache)。

示例 (Nginx):

http {
  server {
    listen 443 ssl http2;
    server_name example.com;

    # ... 其他配置 ...

    location / {
      http2_push /style.css;
      http2_push /script.js;
      http2_push /image.png;
    }
  }
}

在这个例子中，当客户端请求根目录 / 下的资源时，服务器会推送 style.css、script.js 和 image.png 这三个文件。

3.3 在 Network 面板中分析 HTTP/2 推送

在 Chrome DevTools 的 Network 面板中，你可以看到哪些资源是通过 HTTP/2 推送的。推送的资源通常会有一个 Push 类型的 initiator。

你可以通过以下方式来分析 HTTP/2 推送的效果：

• 查看 Waterfall 图： 观察推送的资源是否比其他资源更早到达客户端。
• 查看 Timing 信息： 比较推送的资源和非推送的资源的加载时间。
• 测试不同的推送策略： 调整服务器端的配置，推送不同的资源，并观察对页面加载速度的影响。

3.4 HTTP/2 推送的注意事项

• 不要过度推送： 只推送客户端真正需要的资源。过度推送会浪费带宽，并可能降低页面加载速度。
• 考虑缓存策略： 确保推送的资源具有合理的缓存策略，避免客户端重复下载。
• 使用 Link 头部： 可以使用 Link 头部来指示服务器推送哪些资源。这比在 Nginx 配置文件中硬编码更灵活。

示例：

<head>
  <link rel="preload" href="style.css" as="style">
  <link rel="preload" href="script.js" as="script">
  <link rel="preload" href="image.png" as="image">
</head>

服务器可以根据 Link 头部的信息来推送资源。

四、综合应用：优化一个实际页面

现在，让我们把上面学到的知识应用到一个实际的页面上。假设我们有一个电商网站的商品详情页，页面上有很多图片、CSS 和 JavaScript 文件。

4.1 分析 Waterfall 图

首先，打开 Chrome DevTools 的 Network 面板，加载商品详情页，并分析 Waterfall 图。

• 发现大量的请求排队： 这表明浏览器对同一域名的并发连接数已经达到上限。我们可以使用域名分片来解决这个问题。
• 发现 TTFB 过长： 这表明服务器响应速度慢。我们可以优化后端代码和数据库查询，并使用 CDN 来加速静态资源的加载。
• 发现 Content Download 时间过长： 这表明资源文件太大。我们可以压缩资源文件，优化图片，并使用代码分割来减少 JavaScript 文件的体积。

4.2 调整请求优先级

将首屏需要的图片和 CSS 设置为 fetchpriority="high"，确保它们尽快加载。将非关键的图片和脚本设置为 fetchpriority="low"，避免阻塞首屏渲染。

4.3 启用 HTTP/2 推送

配置服务器，推送客户端可能需要的 CSS 文件、JavaScript 文件和图片。

4.4 测试和验证

在完成上述优化后，重新加载商品详情页，并观察 Waterfall 图的变化。比较优化前后的页面加载时间，验证优化效果。

五、总结

今天我们深入探讨了 Chrome DevTools Network 面板的几个高级功能：Waterfall 图、请求优先级、HTTP/2 推送分析。希望这些知识能帮助你更好地理解网络请求的生命周期，并找到性能瓶颈，从而优化你的网站和应用的加载速度。

记住，性能优化是一个持续的过程，需要不断地学习和实践。希望你们都能成为真正的“网速救星”！ 下课！