103 Early Hints 在代理IP 链路上为什么常常白给？

103 Early Hints 能让浏览器提前去取资源,是一项实打实的提速设计。但在代理IP 链路上,这个提前量经常被中间层吃掉——浏览器等到的还是原来那个完整响应,优化等于白做。

103 是正式响应之前的一小段提示

服务端处理一个请求往往需要时间:查库、拼装、渲染,这段时间里浏览器只能干等。Early Hints 的思路是把等待利用起来——服务端先发一个 103 状态码的提示响应,里面带上资源提示头,告诉浏览器”这些东西待会儿用得上,你现在就可以去取”。

浏览器收到 103 之后就开始预连接、预取,等真正的 200 响应到达时,关键资源已经就位或至少在路上了。省下的是服务端处理那一段空窗期,对首屏的观感影响不小。

关键在于”提前”两个字。同样一句资源提示,放在不同位置,效果差别很大——下面这张表把三种常见位置拆开对比。

中间层为什么会把它吃掉

不透传。部分中间层只处理 200 一类的最终响应,遇到 1xx 这类信息性响应要么丢弃,要么不认识直接放过但浏览器也收不到。走代理IP 时链路多了一段转发,多一处不透传的机会。

缓冲合并。这是更常见的一类:中间层把收到的内容攒一攒再一次性回传,103 和后面的 200 被合并成一个响应。浏览器拿到的时候,”提前量”已经不存在了,整段优化被抹平。

超时策略。等待正式响应的过程中,中间层有自己的超时与连接复用策略。若它认为这一段连接可以复用或需要保持,可能会调整发送节奏,103 的时机优势就没了。

怎么判断有没有生效

看时序。打开开发者工具的网络面板,看关键资源请求的开始时间是不是早于主文档响应完成。提前开始说明 103 起效了,同时开始说明没生效。

看状态码。主文档的请求条目里如果出现 103 这一行,说明浏览器确实收到了提示响应;整条请求只有一个 200,那 103 在路上就被处理掉了。

对比法。同一个地址,直连测一次、走代理IP 测一次,看提前量是否还在。两次结果不同,就能锁定问题出在转发这一段,而不是服务端没下发。

需要说明的是,这项优化不是每个站点都启用,也不是每段代理IP 链路都必须支持。它更像是锦上添花:有,省下几百毫秒;没有,也不影响正常访问。排查时把它排在后面,先把连通性和代理IP 出口地区这类基础项确认了,再来看这一层。

什么时候值得为它折腾

如果站点本身服务端处理时间很短,103 带来的提前量本来就没多少,值不值得为它调整链路要打个问号。真正划算的是那些服务端要查一圈、渲染一通才吐页面的站点——这类页面上,提前量的绝对值才可观。

访问别人的站点时,你基本没有干预手段,能做的主要是判断它有没有被中间层吃掉,以及把这个结论反馈给代理IP 链路的提供方。如果站点是自己维护的,那就可以从服务端下手:确认 103 确实下发了、提示的资源确实是首屏要用到的、以及代理IP 这一段的缓冲策略不会把两段合并。

排查顺序上还有个经验:先看时序,再看状态码,最后做直连对比。三步走完基本能定性,不需要一上来就抓包。