一道面试题，开始性能优化之旅（1）-- beforeFetch

十一闲来无事，最近看了一本关于前端性能的书，而真的看懂一本书的标准就是能用自己的话说明白书中的知识，所以我想来总结一下，但是性能优化又是一个庞杂的话题，该如何说起呢？直到我看到了这道面试题，一道我们再熟悉不过的面试题：

从输入url到页面展示，这个过程中做了什么

一张图直观告诉你答案

图1-1

其实之前遇到这道题，我多半会从浏览器开始解析html开始算起，忽略从navigationStart到responseEnd 流程，我也一直对这段知识盲区视而不见，但是我能感觉到，面试官其实对我的回答并不满意，逃避不是办法，那么我们就来看看每个阶段都做了些啥, **它们又是如何影响前端性能的**

从上图中我们清晰的看到从 navigationStart 到 fetchStart 有一个 redirect 流程，这就是重定向

重定向流程不赘述了，就是下图所示

图2-1

对于未登录用户，服务端返回301 通知浏览器跳到登陆页但是就本人的开发经验，对于未登录的跳转，多半是由前端直接控制，不再受限于重定向实现

这三种情况，本人实际工作中都真实经历过，当时并没有觉得会对性能有什么影响，通过学习，发现重定向确实会对首屏性能有甚至翻倍的影响

其实通过图 2-1，我们也能清楚的看到经过301/302 相当于多了一个请求---响应的耗时，看似不经意的一次重定向使整个访问时间几乎翻倍。

为什么会有翻倍的影响呢？

"多了一个请求---响应的耗时" (核心原因)：
- 如之前解释，重定向（无论是 301 还是 302）强制客户端进行两次完整的 HTTP 事务 ：
  - 第一次事务： 请求原始 URL -> 服务器返回 302 + Location (新 URL)。
  - 第二次事务： 请求新 URL -> 服务器返回最终内容 (200 OK)。
- 每一次 HTTP 事务都包含以下耗时环节（尤其是在网络条件不佳时）：
  - DNS 解析： 将域名解析为 IP 地址（可能发生两次，如果新旧 URL 域名不同）。
  - TCP 连接建立： "三次握手"（可能发生两次，如果新旧 URL 是不同服务器或需要新连接）。
  - TLS 握手： 如果使用 HTTPS，建立安全连接（可能发生两次）。
  - 请求发送： 客户端发送 HTTP 请求数据到服务器。
  - 服务器处理： 服务器处理请求（即使是返回重定向，也需要消耗 CPU 和 I/O 资源）。
  - 响应传输： 服务器将响应数据（即使是小的重定向响应）传回客户端。
  - 客户端处理： 客户端接收、解析响应，并根据 Location 头发起新请求。
- 所有这些环节的耗时在重定向过程中都会至少增加一倍。

通过 http://bing.com 访问时，实际发生了 两次重定向（而非理想的一次）：

第一次重定向
http://bing.com → 302 Found → Location: https://bing.com
（强制升级 HTTPS，但未跳转到规范域名）
第二次重定向
https://bing.com → 302 Found → Location: https://www.bing.com
（跳转到带 www 的规范域名）

步骤	耗时环节
初始请求	DNS 解析 `bing.com` + TCP 握手 + TLS 握手（失败，因 HTTP 明文）
第一次重定向	服务器响应 `302`（约 1 RTT）
第二次请求	DNS 解析 `bing.com`（可能复用） + TCP 握手 + 完整 TLS 握手（HTTPS）
第二次重定向	服务器响应 `302`（约 1 RTT）
第三次请求	DNS 解析 `www.bing.com` + TCP 握手 + TLS 握手 + 最终内容传输

关键性能损耗：

为什么 Bing 未优化？

diff 复制代码

  # 邮件原始内容
- 促销链接：http://short.url/SUMMER2023
+ 促销链接：https://www.example.com/campaigns/summer2023

次选方案 ：
✅ 合并重定向 - 配置短链直跳HTTPS
nginx 复制代码
```
location /s/ { return 302 https://$host$request_uri; }
```

plaintext 复制代码

外部应用点击 → 启动浏览器进程 → 创建标签页 → 发起请求 (此时才开始前端性能监控)

致命问题 ：浏览器冷启动时间（200ms~2000ms）被错误计入前端性能指标中的 navigationStart → fetchStart 阶段。

以上，对于 beforeFetch(navigationStart→fetchStart的阶段)，如果beforeFetch阶段明显增加，我们可以优先考虑是不是有重定向行为或者端外引流的场景导致冷启动，问题定位后，解决也就是水到渠成的事了