HTMLEarlyHints103状态码详解与应用

HTML Early Hints（HTTP 103 状态码）是一种前沿的性能优化机制，它让服务器在发送完整 HTML 响应前，通过 Link 响应头“提示”浏览器即将用到的关键资源（如 CSS、字体等），从而触发 DNS 预解析、TCP 预连接或预加载——但不传输内容、不强制执行，完全由支持该特性的现代浏览器（如 Chrome 103+）自主决策；其真实价值在于精准协同：仅对 HTML 中实际引用的资源生效，且高度依赖 HTTP/2 或 HTTP/3、正确服务端配置（如 Nginx 的 early_hints on）、绝对路径 Link 头及端到端链路兼容性，稍有偏差便成无效提示；想真正提速首屏渲染？它不是银弹，而是一把需要精细校准的“性能钥匙”。

什么是 Early Hints（103）及其真实作用边界

Early Hints 不是“让浏览器提前加载资源”，而是让服务器在发送完整响应前，用 103 Early Hints 状态码 + Link 响应头，提示浏览器“接下来主响应里会用到这些资源”。浏览器收到后可提前发起预连接、DNS 预解析、甚至预加载（preload）——但是否执行、何时执行、加载哪些，完全由浏览器策略决定（Chrome 103+ 支持，Firefox 尚未支持，Safari 无计划）。

关键点在于：103 本身不传输任何资源内容，也不保证资源一定被提前获取；它只是个“提示”，且只对后续主响应中实际引用的资源生效（比如 Link: ; rel=preload; as=style，但 HTML 里没引入 style.css，那这个提示就白发了）。

如何在 Nginx 中正确启用 103 Early Hints

Nginx 从 1.21.4 开始原生支持 103 Early Hints，但需手动开启并精确配置：

• 必须启用 http_v2（HTTP/2 或 HTTP/3），HTTP/1.1 下无效
• 在 server 或 location 块中添加：early_hints on;
• 使用 add_header Link 手动注入提示，例如：add_header Link "; rel=preload; as=style", "; rel=preload; as=image";
• 注意：Link 头必须在 103 响应中发出，不能放在最终 200 响应里；Nginx 会自动将匹配的 add_header Link 提前到 103 响应中（前提是 early_hints on 已启用）
• 错误示范：add_header Link 写在 if 块或某些 proxy_pass 后置逻辑里——Nginx 可能无法将其提升至 103 阶段

示例最小配置：

server {
    listen 443 ssl http2;
    early_hints on;
    location / {
        add_header Link "; rel=preload; as=style";
        add_header Link "; rel=preload; as=font; crossorigin";
        proxy_pass http://backend;
    }
}

Node.js（Express）中手动发送 103 的实操要点

Express 本身不内置 103 支持，需绕过框架直接操作底层 res.socket，且仅限 HTTP/2 连接：

• 先检查 res.httpVersion === '2.0'，否则跳过（HTTP/1.1 下发 103 会被忽略或报错）
• 调用 res.push()（HTTP/2 Server Push）不是 103 ——这是常见混淆点：res.push() 是主动推送资源体，103 只是发 Link 头
• 正确做法：用 res.write('\r\n', 'binary') 触发响应头发送，并手动写入状态行和 Link 头（需严格遵循 HTTP/2 二进制帧格式）
• 更稳妥方案：改用原生 http2 模块，调用 stream.pushStream() 发送 103 帧，或使用封装库如 early-hints（注意其仅在 res.flushHeaders() 前生效）

简化实践建议：

• 避免在 Express 中硬编码 103，优先用 Nginx 或 CDN（Cloudflare、Fastly）层处理
• 若必须 Node 层控制，用 http2 原生 API + const { createSecureServer } = require('http2')
• Link 中的 as= 值必须与后续 HTML 中实际使用方式一致（例如 对应 as=style，写成 as=script 会导致预加载被忽略）

验证 103 是否生效及典型失效原因

打开 Chrome DevTools → Network → 刷新页面 → 查看第一个请求（通常是 HTML）的响应头，找是否有 Status: 103 Early Hints，并确认 Link 头存在且格式合法。

常见失效场景：

• 浏览器不支持（Chrome < 103、Edge < 103、Firefox/Safari 全不支持）
• 服务端未启用 HTTP/2（Nginx 日志里看到 http/1.1）
• Link 中路径为相对路径（如 ），必须是绝对路径（）或完整 URL
• 主响应（200）HTML 中未实际引用该资源（比如提示 preload /data.json，但页面用 fetch('/api/data')）
• CDN 或中间代理（如某些 WAF）吞掉了 103 响应或重写了 Link 头

真正起效时，你能在 Network 面板看到资源请求时间线明显前移（比如 main.css 的 DNS 查找、TCP 连接、TLS 握手在 HTML 200 返回前就开始了），但这需要对照 Waterfall 仔细比对，不能只看有没有 103 状态码。

早期提示的价值高度依赖部署环境一致性——从 TLS 配置、HTTP/2 协商，到 CDN 缓存策略、浏览器版本分布，漏掉任意一环，103 就只是多发了一个空响。

好了，本文到此结束，带大家了解了《HTMLEarlyHints103状态码详解与应用》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！