我最近一阵子在重构我的博客，恰巧之前一阵子准备秋招的时候背八股时看到了 HTTP/2 的服务端推送，于是便尝试在部署阶段为我的博客配置好 HTTP/2 的服务端推送，试图以此来进一步优化首屏加载速度。
HTTP/2 服务端推送为什么能提升首屏加载速度
如下图，在传统的 HTTP/1.1 中，浏览器会先下载 index.html 并完成第一轮解析，然后再从解析出的数据中拿到 css/js 资源的 url，再进行第二轮请求，在 tcp/tls 连接建立后最小需要两个 RTT 才能取回完整渲染页面所需的资源。
而在 HTTP/2 的设想中，流程则是像下面这张图一样。当浏览器请求 index.html 时，服务端可以顺带将 css/js 资源一起推送给客户端，这样在 tcp/tls 连接建立后最小只需要一个 RTT 就可以将页面渲染所需的资源取回。
为了在 HTTP/1.1 中尽可能减少后续的请求，前端开发者尝试了非常多的优化手段，正如 Sukka 在《静态资源递送优化：HTTP/2 和 Server Push》一文中所讲：
关键资源、关键渲染路径、关键请求链的概念诞生已久，异步加载资源的概念可谓是老生常谈：懒加载图片、视频、iframe，乃至懒加载 CSS、JS、DOM，懒执行函数。但是，关键资源递送的思路却依然没有多少改变。
HTTP/2 的 Server Push 创造了新的资源递送思路，CSS/JS 等资源不用随着 html 一起递送也能在一个 RTT 内被传送到客户端，而这一部分资源可以被浏览器缓存起来，不被 html 那较短的 TTL 所限制。
初步方案
既然理清了 HTTP/2 服务端推送的优势，于是准备着手优化。我的博客是纯静态的，通过 DNS 进行境内外分流：境内流量会访问到 DMIT 一台带有 cmin2/9929 网络优化的 vps 上，通过 caddy 提供服务；境外流量则是直接打到 vercel，借助 Amazon 的 CDN 为全球网络提供边缘加速。网络架构大概是下面这个样子：
Caddy 可以通过 http.handlers.push 模块实现 HTTP/2 的服务端推送，在 Caddyfile 中我们可以编写简单的推送逻辑，这没问题；vercel 平台则没有给开发者提供 HTTP/2 服务端推送的配置项，但好在我是静态博客，对平台依赖性不强，考虑迁移到 Cloudflare Workers，五年前就有开发者实现了。
客户端的支持情况
历史上主流浏览器引擎（Chrome/Chromium、Firefox、Edge、Safari）曾普遍支持服务器推送技术。
2020 年 11 月，谷歌宣布计划在其 Chrome 浏览器的 HTTP/2 及 gQUIC（后发展为HTTP/3）实现中移除服务器推送功能。
2022 年 10 月，谷歌宣布计划从Chrome浏览器中移除服务器推送功能，指出该扩展在实际应用中性能不佳、使用率低且存在更优替代方案。Chrome 106 成为首个默认禁用服务器推送的版本。
2024 年 10 月 29 日，Mozilla 发布了 Firefox 132版本，因“与多个网站存在兼容性问题”移除了对HTTP/2服务器推送功能的支持。
至此，主流浏览器对 HTTP/2 服务端推送（Server Push）的支持已全部终结。从最初被视为“减少往返延迟、优化首屏加载”的创新特性，到最终被全面弃用，HTTP/2 推送的生命周期不过短短数年，成为 Web 性能优化历史上的一次重要实验。
替代方案
1. HTTP 103 Early Hints
103 Early Hints 是对服务端推送最直接的“继任者”。它是一个信息性的 HTTP 状态码 (Informational Response)，允许服务器在生成完整的 HTML 响应（例如，状态码为 200 OK）之前，先发送一个带有 Link 头部的“早期提示”响应。
这个 Link 头部可以告诉浏览器：“嘿，我还在准备主菜（HTML），但你可以先去把配菜（CSS、JS）准备好”。这样，浏览器就能利用服务器的“思考时间”提前开始下载关键资源或预热到所需源的连接，从而显著缩短首屏渲染时间。
与服务端推送的对比：
- 决策权在客户端：Early Hints 只是“提示”，浏览器可以根据自身缓存情况、网络状况等因素决定是否采纳该提示。这就解决了服务端推送最大的痛点——服务器无法知晓客户端缓存而导致推送冗余资源。
- 兼容性更好：它是一种更轻量、更易于中间代理服务器理解和传递的机制。
103 Early Hints 对动态博客很有意义，在后端进行计算之前先把需要的资源通过 103 响应告知浏览器，让浏览器先取回其他资源，再等待后端返回最终的 html；而对于我这种产物都是预构建好的静态博客，完全没有任何意义，网关有那个发 103 响应的闲工夫完全可以把 html 直接发过去了。
2. 资源提示（Resource Hints）: Preload & Prefetch
早在服务端推送被弃用前，通过 <link>标签实现的资源提示就已经是前端性能优化的常用手段。它们将资源加载的提示声明在 HTML 中，由浏览器主导整个过程。
<link rel="preload">: 用于告诉浏览器当前页面必定会用到的资源，请以高优先级立即开始加载，但加载后不执行。比如，隐藏在 CSS 深处的字体文件或由 JS 动态加载的首屏图片。通过 Preload，可以确保这些关键资源能尽早被发现和下载，避免渲染阻塞。<link rel="prefetch">: 用于告诉浏览器用户在未来可能访问的页面或用到的资源，请在浏览器空闲时以低优先级在后台下载。例如，在文章列表页 prefetch 用户最可能点击的文章页面的资源，从而实现近乎“秒开”的跳转体验。
Preload 和 Prefetch 将资源加载的控制权完全交给了开发者和浏览器，通过声明式的方式精细化管理资源加载的优先级和时机，是目前最成熟、应用最广泛的资源预加载方案，但仍然逃不过 2 RTT 的魔咒。
尾声：写给一个理想主义者的挽歌
写到最后，我终究是没能为我的博客配上 HTTP/2 服务端推送。
HTTP/2 Server Push 已事实性“死亡”，我很怀念它。
在一个理想模型里，当浏览器请求 HTML 时，服务器顺手将渲染所需的 CSS 和 JS 一并推来，将原本至少两次的往返（RTT）干脆利落地压缩为一次。这是一个如此直接、如此漂亮的解决方案，几乎是前端工程师面对首屏渲染延迟问题时梦寐以求的“银弹”。它背后蕴含的是一种雄心勃勃的魄力：试图由服务端一次性地、彻底地解决“关键请求链”的延迟问题。
但 Web 的世界终究不是一个理想的实验室。它充满了缓存、重复访问的用户、以及形形色色的网络环境。
服务端推送最大的魅力，在于它的“主动”，而它最大的遗憾，也恰恰源于这份“主动”。它无法知晓浏览器缓存中是否早已静静躺着那个它正准备满腔热情推送的 style.css 文件。为了那一小部分首次访问用户的极致体验，却可能要以浪费更多再次访问用户的宝贵带宽为代价。
Web 的演进最终选择了一条更稳妥、更具协作精神的道路。它将决策权交还给了最了解情况的浏览器，整个交互从服务器的“我推送给你”，变成了服务器的“我建议你拿”，再由浏览器自己定夺。这或许不够浪漫，不够极致，但它更普适，也更健壮。
所以，我依然会怀念那个雄心勃勃的 Server Push。它代表了一种对极致性能的纯粹追求，一种美好的技术理想主义。尽管它已悄然淡出历史舞台，但它所指向的那个关于“速度”的梦想，早已被 103 Early Hints 和 preload 以一种更成熟、更懂得权衡的方式继承了下来。