摘要

  • W3C 2014 年 10 月的首份公开 Resource Hints 草案提出 preconnect：当网页已知将使用的来源、尚未知具体资源网址时，可提示浏览器提前做 DNS 查询、TCP 握手，以及适用时的 TLS 协商。
  • 后来的草案把 dns-prefetch、preconnect、prefetch、prerender 区分开。网页给线索，浏览器依据设备与网络状态决定完整连接、只做一部分，或不采取动作。

照片墙里有许多照片，下一张由读者选择。网页知道图库服务器的地址，却猜不准读者会点谁。此时把整排照片都下载过来，未免像客人还在门口犹豫，厨房已把菜单全做了一遍。但浏览器至少可以考虑先与图库服务器打个招呼。preconnect 利用的正是“知道来源”和“知道具体文件”之间的时间差。

W3C 2014 年 10 月 21 日的首份公开草案将提前连接写成网页作者或服务器给浏览器的提示。文本列出可提前完成的工作：DNS 解析、TCP 握手，以及可选的 TLS 协商。当时同篇草案还讨论 preload，那是针对要取回的具体资源。两者的边界很清楚：提前联系一家餐厅，不等于提前替访客点餐，更不等于菜已经上桌。

2017 年 5 月 4 日的工作草案呈现了四类提示。dns-prefetch 先查域名；preconnect 走向来源的连接建立；prefetch 针对未来可能需要的资源发起提取；prerender 甚至可以准备将来要访问的页面。一个知道“去哪里”，另一个猜“拿什么”，后两个还可能做更多事。把它们混成一句“浏览器提前加载”，就会看不见每种猜测的成本。

2019 年 6 月 27 日的草案专门举出动态网址的情形：网页构建过程中，资源的完整网址可能稍后才确定，但它所属的来源早已可知。提前完成连接协商，待文件网址出现时，浏览器便有机会少等一道门槛。这里没有神奇的预知能力，只有一条恰好早到的地址信息。

能提前握手，不代表应该见谁都握。2020 年 10 月 5 日的工作草案把裁量交给浏览器：可尝试完整握手，也可只做部分步骤，或因资源限制而跳过。每个来源开多少连接，也由浏览器根据协议、网络状况、设备能力和总连接限制决定。网页可以递来十张订位纸，浏览器没有义务替它占满整家店。

这份裁量会影响读者眼前的页面。提前联系最终用不到的来源，消耗了真实的网络与设备资源；大量投机连接可能与当前必需的下载争抢。2020 年草案还规定，未完成的 preconnect 工作不应拖慢文档的 load 事件。为了可能出现的下一盘菜，让已经上桌的菜一直等着，餐厅再热情也说不过去。

W3C 的发布沿革从 2014 年首份公开草案记起，列出后续多个工作草案。文件里的提示家族逐渐分工：查名字、建连接、取资源、准备页面，各做各的事。它们当时都是草案。支撑这个设计的观察却很日常：网页可能先知道下一通电话打给谁，后知道要说什么。浏览器拿到号码，再决定现在打是否划算。