HTTP 103 Early Hints 是什么？它如何帮助浏览器提前加载资源？

简化版

103 Early Hints 是一种 1xx 临时响应。

服务端可以在最终响应生成前，先用 103 告诉浏览器一些可能需要预加载的资源，例如 CSS、JS、字体。浏览器收到后可以提前建立连接或发起 preload，从而减少页面等待。

它不代表最终响应成功，后面仍然会有 200、404 等最终状态码。

详细版

示例：

HTTP/1.1 103 Early Hints
Link: </app.css>; rel=preload; as=style
Link: </app.js>; rel=preload; as=script

随后服务端返回最终响应：

HTTP/1.1 200 OK
Content-Type: text/html

它适合后端生成 HTML 较慢，但关键静态资源可以提前确定的场景。

浏览器可以利用这段时间提前请求资源。

103 的效果依赖浏览器、CDN、代理链支持，也要避免错误预加载浪费带宽。

完整版教学

1. 先说明 103 属于什么响应

HTTP 状态码 1xx 是信息性响应。

它表示请求还在继续处理，客户端后面还会收到最终响应。

103 Early Hints 的作用是“提前提示”。

服务端最终页面还没生成完，但已经知道页面可能需要哪些关键资源，就先告诉浏览器。

103 不是业务成功，只是让浏览器早点知道资源线索。

2. 典型响应流程

客户端请求页面：

GET /home HTTP/1.1
Host: example.com

服务端先返回：

HTTP/1.1 103 Early Hints
Link: </main.css>; rel=preload; as=style
Link: </main.js>; rel=preload; as=script

浏览器可以开始加载 CSS 和 JS。

后端继续渲染页面，最后返回：

HTTP/1.1 200 OK
Content-Type: text/html

这样资源加载和 HTML 生成可以部分并行。

3. Link preload 是关键

103 常搭配 Link 头。

例如：

Link: </font.woff2>; rel=preload; as=font; crossorigin

它告诉浏览器提前加载字体。

如果没有 103，浏览器可能要等 HTML 下载并解析到相关标签后才发现资源。

提前发现资源能减少关键渲染路径等待。

4. 适合哪些场景

场景	是否适合	原因
SSR 页面生成较慢	适合	静态资源可提前加载
静态 HTML 秒回	收益较低	本来很快能发现资源
关键 CSS/JS 固定	适合	预加载命中率高
个性化资源不确定	谨慎	错误预加载浪费带宽
API JSON 接口	通常不适合	没有浏览器渲染资源链

103 的收益来自提前暴露关键资源。

如果资源本来就能很快被发现，收益就有限。

5. 和 Server Push 的区别

HTTP/2 Server Push 是服务端主动把资源推给客户端。

103 Early Hints 只是告诉客户端“你可以去请求这些资源”。

客户端仍然掌握是否请求、如何缓存、优先级如何安排。

这比 Server Push 更温和，也更容易避免推错资源。

很多场景里，103 配合 preload 比盲目 push 更可控。

6. 工程落地注意点

使用 103 要考虑全链路支持。

浏览器是否支持。
CDN 是否透传 103。
反向代理是否会吞掉 1xx。
框架是否允许发送临时响应。
Link 指向的资源是否稳定。
预加载资源是否真的关键。

如果代理不透传，应用发了 103 也可能到不了浏览器。

如果预加载资源过多，会抢占带宽，反而影响首屏。

7. 常见误区与追问

误区：103 表示页面请求成功。 它只是临时响应，最终状态码还在后面。
误区：103 会直接把资源推给浏览器。 它只是提示资源，是否请求由客户端决定。
误区：预加载越多越好。 过多 preload 会浪费带宽并干扰优先级。
追问：103 和 100 Continue 有什么相同点？ 都是 1xx 临时响应，后面还有最终响应。
追问：为什么 SSR 场景适合 103？ HTML 生成期间可以提前加载确定的关键资源。
追问：CDN 不支持会怎样？ 103 可能被吞掉，优化效果消失。

8. 加强记忆

103 可以记成“HTML 还在做饭，先把菜单上的 CSS 和 JS 告诉浏览器”。

答题时围绕临时响应、Link preload、提前发现资源、全链路支持讲。

简化版

详细版