HTML 103 Early Hints优化技巧

103 Early Hints 是一项被低估却极具潜力的HTTP性能优化技术——它让服务器在发送完整HTML响应前，抢先通过轻量级103状态码和Link响应头告知浏览器哪些关键资源（如CSS、字体、第三方域名）需要预加载或预连接，从而显著加速首屏渲染；虽然HTML本身不参与发送逻辑、仅作为静默受益者，但其性能提升效果真实可观，尤其在Chromium和新版Safari中已原生支持；不过它并非“开箱即用”，需后端服务器（Nginx/OpenResty、Apache扩展、Node.js框架或Cloudflare等平台）主动配置，且对协议版本、CDN策略、Link头格式和跨域规则极为敏感——对追求极致加载速度的团队而言，它是值得投入验证的进阶利器，而对多数项目，它更像一把精准的手术刀：用得巧，事半功倍；用错一步，便悄然失效。

HTML 本身无法主动触发或发送 103 Early Hints 响应——它只是接收方，不是发起方。真正需要配置的是服务器（如 Nginx、Apache、Node.js 后端），HTML 只负责在收到 103 后正确解析并预加载资源。

什么是 103 Early Hints？它和 HTML 有什么关系？

103 Early Hints 是 HTTP/1.1 扩展状态码（RFC 8297），允许服务器在最终响应（如 200 OK）发出前，先发一个轻量级响应头，提前告知浏览器：「接下来会用到这些资源，现在就可以开始预加载」。

HTML 不生成这个响应，但它是受益者：浏览器拿到 Link 头里的 preload 或 preconnect 指令后，会立即启动 DNS 查询、TCP 连接、TLS 握手或资源下载，从而缩短首屏渲染时间。

关键点：

• 103 必须由服务器在 200 响应之前发出；HTML 页面本身不参与发送逻辑
• 浏览器只认响应头中的 Link 字段， 标签在 HTML 中写是「后置」行为，和 103 无关
• 目前仅 Chromium 内核（Chrome、Edge、Opera）和 Safari 16.4+ 支持，Firefox 尚未实现

如何让服务器发出 103 Early Hints？

必须在 Web 服务器或应用层显式构造并发送该响应。常见方式：

• Nginx：需编译时启用 --with-http_v3_module 并配合 early_data on（实际生产中极少直接支持 103，更推荐用 OpenResty + Lua 手动发头）
• Apache：需启用 mod_http2，并在响应前用 Header add Link 配合 H2Push on ——但 Apache 原生不支持主动发 103，需模块扩展
• Node.js（Express / Fastify）：可调用 res.push()（HTTP/2 Server Push，已废弃）或直接写入 res.write() 发送带 103 状态行的响应头（注意：必须在 res.end() 前且不能有 body）
• Cloudflare、Vercel、Netlify 等平台：部分支持自动注入（如 Cloudflare 的 Early Hints 功能需在仪表盘开启，且只对静态 HTML 路径生效）

示例（Fastify）：

fastify.addHook('onSend', async (request, reply) => {
  if (reply.raw.writable && !reply.sent) {
    reply.raw.write('HTTP/1.1 103 Early Hints\r\n');
    reply.raw.write('Link: ; rel=preload; as=style\r\n');
    reply.raw.write('Link: ; rel=preconnect\r\n');
    reply.raw.write('\r\n');
  }
});

HTML 中怎么配合 103 做预加载？

不需要额外写 HTML 代码。只要服务器正确返回了 103 响应头，浏览器就会自动处理其中的 Link 字段——你甚至看不到它出现在开发者工具的「Network」标签页主请求里（Chrome DevTools 目前不显示 103 条目，只能用 chrome://net-internals/#events 查看）。

但要注意避免冲突：

• 如果 HTML 中同时写了 ，而 103 也推送了同一资源，浏览器不会重复加载，但可能浪费一次解析开销
• 103 中的 as 值必须准确（如 as=script、as=font），否则预加载可能被忽略或降级为普通 fetch
• 跨域资源需确保 Link 中的 URL 满足 CORS 要求，否则字体等资源可能加载失败

验证是否生效？常见失效原因

最可靠的方式是抓包（Wireshark / curl -v）或使用 Chrome 的 netlog：

• curl -v https://yoursite.com 若看到 < HTTP/1.1 103 Early Hints 行，说明服务器发出了
• Chrome 访问 chrome://net-internals/#events，筛选 HTTP_STREAM_JOB，查找 103 类型事件
• 用 Lighthouse 检测「Preload key requests」得分提升，是间接证据

容易被忽略的坑：

• HTTP/1.1 不支持 103，必须走 HTTP/2 或 HTTP/3
• CDN 缓存了 200 响应但没缓存 103，导致后续请求收不到早期提示
• 服务器在 103 后又返回了 301 或 302，浏览器会丢弃 103 中的 Link（规范要求）
• Link 头值必须用英文双引号包裹 URL，且含完整 scheme（https://），少一个字符都会让整个头失效

真正在意性能的人，会先确认服务器链路是否可控、是否值得为 103 投入运维成本——对大多数中小项目，用 + resource-hints 已足够，103 是锦上添花，不是雪中送炭。

今天关于《HTML 103 Early Hints优化技巧》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！