preconnect指着的域名，有8个已经不存在了

摘要：122个海外品牌站的首页上一共3102条资源提示，其中201条指向的域名在整个页面里连一次都没被用到。拆开看差别惊人：打包工具自动生成的那1642条模块预加载，空转数是0；人手写进模板的419条预连接，125条空转，占29.8%。逐个域名验活还查出8个已经不解析的主机，其中6个属于同一个品牌的中国站子域，1个是某下线服务的旧地址，还有1个干脆是没被替换的模板变量。文中给出分类型空转率、重复声明规模、字体预加载的101条常见错写、两次快照的变更率，以及一套删之前必须先确认的判据。

八月二十日有篇文章翻出了一件旧事：二十多年前做SEO的人爱把关键词写成白底白字藏在页面里，如今同样的手法出现在一份法庭文件里，只不过藏的是给大模型看的指令。

这件事真正的看点不是手法多新，而是页面上给机器看的那些东西，通常没有人负责清理。用户看不见它，视觉走查看不见它，改版的时候也没人会专门去问一句它还在不在用。

网页里这类东西不止一种。今天说的是最不起眼的那一类：写在头部、告诉浏览器提前去连接某个域名的资源提示。它每一行都只有几十个字符，加进去几乎没有成本，删掉也没人会注意。

这类提示的处境有点特殊。它不像标题描述那样会被人反复打磨，也不像脚本那样出错就白屏。它介于两者之间：出了问题不会有人发现，做对了也没人会夸。于是它就一直躺在那儿，跟着模板从一次改版走到下一次改版。

更要命的是，它描述的根本不是自己站上的东西——它描述的是你跟哪些外部服务有往来。而外部服务换起来，可比模板勤快多了。

保哥把这批品牌站的首页快照翻出来，把每一条提示指向的域名跟页面上实际加载的资源逐一比对，想看看这些提前连接到底连给了谁。

首页上那些预连接声明，有多少真的连上了东西？

先把这件事的判据说清楚。一条提示写着某个域名，意思是浏览器应该提前跟它握手，因为待会儿要从那儿取东西。判断它有没有白写，只要看这个域名在页面上有没有对应的资源被加载。

这里得先回答做SEO的人一定会问的一个问题：这些提示对搜索引擎有没有直接影响？没有。抓取程序并不执行这类提示，它们只对真实用户的浏览器生效。所以这块配置的收益是绕了一圈的——先影响真实用户的加载体验，体验数据再影响体验指标，体验指标才影响排名。这条链路比多数人以为的长，而它长期没人管，恰恰也是因为它长。没有哪个环节会因为它写错而直接报警。

怎么算一条空转

比对分两层。硬判据是这个域名有没有出现在页面加载的资源地址里——脚本、样式表、图片、字体、内嵌页面、视频源、背景图，全都算。软判据放宽到整个页面文本里有没有再提到过这个域名，这能把藏在脚本字符串里的接口地址也捞进来。

两层都没命中，才算完全空转。这个口径是偏保守的，也就是说真实的浪费只会更多。

这次没算进去的几件事

有四类情况被排除在外，先说清楚。

一是只在特定交互后才加载的资源。用户点开聊天窗、展开尺码表、切换支付方式，这些动作触发的请求不在静态源码里。所以软判据那一层特意放宽到了全文搜索，能把大部分写死在脚本里的接口地址捞回来。

二是首屏之后才用到的域名。抓取拿到的是完整HTML，不区分首屏与非首屏，所以只要页面上有对应资源就算命中，不管它在第几屏。

三是指向自己域名的提示。这类在样本里不少，但它们的成本和收益都跟第三方不是一回事，单独统计意义不大，只在总数里出现。

四是抓不到首页的站。168个站是能拿到完整首页的那一批，剩下的不在任何分母里。

样本与规模

168个品牌站的首页快照里，122个站写了资源提示，一共3102条。每站的中位数是12条，平均25.4条。

写得最多的一个站有244条，其次是192条、169条、130条。这些数字本身就值得看两眼——一个首页需要提前握手244次，这件事怎么想都不太对。

452条没加载资源，201条连提都没提

3102条里有452条指向的域名没有任何资源被加载，占14.6%。把口径收紧到整页文本都没再出现的，还剩201条，占6.5%。

这种写下去却找不到接收方的声明，不止资源提示这一类。同一批站的爬虫规则文件里也量到过接近的比例。它们的共同点是：写的那天有明确用意，写完之后没有任何东西会告诉你那个接收方已经不在了。

站级看：122个站里53个站完全没有空转，6个站的空转比例过半，没有任何一个站是全部空转。空转最集中的几个站是这样的：

为什么构建工具生成的那批一条都不空转？

把3102条按类型拆开之后，出现了本文最干净的一组对照。

五种类型，空转率差着几十倍

前两类加起来1864条，空转数是零。后两类加起来676条，空转197条。

这五种写法在HTML规范定义的链接关系清单里各有各的语义，不是一回事，但它们共用同一个书写位置，也共用同一种命运。

差别不在重要性，在于谁把它写出来的

前两类几乎全部由打包工具在构建时自动生成。工具知道这次构建产出了哪些代码块、哪些块会被哪个页面用到，于是把对应的提示写进去。下一次构建时，这批提示会被整个重新生成一遍——依赖变了，提示跟着变。

后两类通常是人手写进模板的。某天要接一个新的分析工具，文档说加一行提前建连能快一点，于是加了。这一行从此躺在模板里，没有任何东西会在依赖变化时提醒它该走了。

这条对照能解释掉大部分现象

顺着这个思路再看前面那张站级空转表就明白了：空转多的站不是技术差，而是这块配置的年头久、经手的人多。空转为零的53个站里，有相当一批压根就只写了构建工具生成的那几类。

换个说法：一条配置能不能长期保持正确，跟当初写它的人有多认真关系不大，跟它背后有没有一个会自动重写它的程序关系极大。

那4条预加载空转是怎么回事

资源预加载这一类空转率只有0.7%，4条。它的特殊之处在于必须写明要预加载的具体文件，而不只是一个域名——文件路径写错了浏览器会在控制台报错，写对了就一定会被用到。

这也提示了一个通用的改法：把声明写得越具体，它出错时越容易被发现。只写一个域名的声明，错了是完全静默的。

用模块预加载的那36个站是什么来路

1642条模块预加载集中在36个站上，平均每站45条，这个密度远高于别的类型。它们的共同点是前端用了现代打包工具做代码分割——页面被拆成很多小块，按需加载，构建时顺手把这一页需要哪几块写进头部。

另外86个有提示的站一条模块预加载都没有。这不是它们做得差，只是技术栈不同：用传统模板渲染的站没有代码分割这回事，自然也就没有这类提示。

所以这组对照还有一层含义：把配置交给程序生成，前提是你的技术栈里真的有那个程序。手写模板的站没有这个便利，只能靠流程和检查来补。

被指着却已经不解析的8个域名是谁？

空转还只是没用上，更彻底的一种是那个域名今天已经不存在了。把所有第三方主机拿去逐个查一遍，一共196个，其中8个在域名解析这一层就查无此名。

6个属于同一个品牌的中国站

这8个里有6个来自同一个站的首页：分析、静态资源、安全下单、通用服务、账号统一登录，各占一个子域，全部挂在同一个中国站主域下面。

它们在页面上的角色是域名预解析，也就是让浏览器提前把域名翻译成地址。今天这一步会直接失败，因为解析不出任何结果。

需要说清楚的是，这不代表那个品牌的中国业务怎么样了，只代表这6个具体的子域名今天在公开解析里没有记录。而首页上那几行提示还老老实实指着它们。

1个是已经下线的服务旧地址

另一个不解析的主机来自某个电商平台的产品评论服务。那个服务几年前就停止提供了，商家被要求迁到别的方案上。

迁移那一步显然做了，因为页面上已经看不到它的任何资源。没做的是回头把头部那一行删掉——它不属于任何一次迁移清单，因为它不影响功能。

还有1个根本不是域名

最后一个查无此名的主机长这样：一对花括号包着一个变量名。这是模板引擎里的占位符，本该在渲染时被替换成真实地址，结果原样输出到了页面上。

浏览器拿到这一行会怎么处理？它会试着把这串字符当域名去解析，然后失败。整个过程没有任何报错会浮到运营那一层。

这一条特别值得单独拎出来，因为它证明了一件事：这块配置没有任何人在看。一个明显到只要打开页面源码就能发现的错误，能在首页上留到今天。

剩下那些查回来的状态码不能直接当死活看

196个主机里有80个返回正常，27个连不上，其余是各种拒绝或未找到。这里必须提醒一句：内容分发网络的根地址返回未找到是完全正常的，它本来就不提供根路径的页面。所以那50个未找到里绝大多数是活的。

能当硬证据的只有解析层的失败，也就是前面那8个。这条边界不划清楚，很容易把一份体检报告写成危言耸听。

那27个连不上的主机要分开看

还有27个主机域名能解析，但根地址请求不回来任何东西。这一类不能直接判死。

常见的原因有三种：只对特定地区开放，只接受特定来源的请求，或者干脆只响应某几个具体路径而不响应根路径。前两种在跨境场景里非常普遍——我这台机器在境内，拿到的待遇跟目标用户所在地区完全不同。

这里要固化一条做法：跨站测量的每一个失败，都要先分清是这个地址坏了，还是这台机器不被接待。不做这一步，一份报告里的失败率可以轻松虚高一倍。真正能拿去当结论的，只有解析层那8个——域名不存在这件事对谁都一样。

同一个域被声明两遍甚至十遍，是怎么攒出来的？

3102条提示里有2196条是重复的——同类型、同域名、同用途，在同一个页面里出现了不止一次。涉及98个站。

重复最多的几个站，量级相当夸张

写了244条提示的那个站里有230条是重复；192条的那个站重复189条；169条的重复166条。也就是说，这些站的提示数量看着吓人，实际去重之后往往只剩十几条。

这类重复几乎不可能是人手敲出来的。更可能的成因是模板片段被循环渲染，或者同一个组件在页面上出现多次而每次都带上了自己那份头部声明。

重复本身伤害不大，但它掩盖了真问题

浏览器对重复的提示会去重处理，所以额外的连接不会真的发起。真正的代价在两处：一是页面体积白白变大，二是任何人打开源码想清点这块配置时，都会被这堆重复淹没。

清点不了，就没人会去清。这是一个自我维持的循环。

另一种冗余：同一个域既预解析又预建连

还有74条属于另一种冗余，涉及30个站：同一个域名既写了域名预解析，又写了提前建连。

这两件事是包含关系——提前建连本身就包含了域名解析这一步，还额外做了传输层握手。两个都写，后面那个把前面那个完全覆盖了。

这种写法通常来自一种保险心态：不确定浏览器支持哪个，两个都写上。这个理由在很多年前成立，今天已经不成立了。

重复到底是怎么攒出来的

把重复最多的那几个站的源码翻开，成因基本是三种。

第一种是组件自带。一个商品卡片组件里写了它需要的图片域名提示，页面上放了48个商品卡片，这一行就出现48次。写组件的人当时并不知道它会被这样使用。

第二种是多个应用各写各的。装了六个第三方应用，每个都往头部塞自己那份，其中四个用的是同一个内容分发域。

第三种是模板继承。父模板写了一份，子模板为了保险又写了一份，两边都没删。

三种成因有个共同点：每一处单独看都是合理的，问题只在合起来之后才出现，而没有人站在合起来那个位置上看过。

字体预加载那101条为什么等于白写？

资源预加载这一类总共562条，空转率极低，看上去是最健康的一类。但它有另一种毛病，而且发生率不低。

用途分布

字体排第一并不意外，它是首屏渲染里最容易拖后腿的一环。

另外三类各有各的坑

样式表预加载140条。这一类最容易写成多余——如果那个样式表本来就是用普通方式在头部引入的，浏览器本来就会以最高优先级去取，再预加载一次没有增量，只是多一行。

脚本预加载101条。它的风险是打乱执行时机：预加载只负责把文件取回来，不负责执行。如果原本靠加载顺序保证的依赖关系没理清，可能出现文件早就到了、执行却仍在等别人的情况。

图片预加载89条。这一类收益最直接——首屏那张大图提前取，能实打实缩短最大内容渲染的时间。前提是选对了那一张。判断办法很简单：用性能面板跑一次，看它认定的最大内容元素是不是你预加载的那一张。选错的话不但没提速，还占了带宽。

224条字体预加载里，101条少写了一个属性

字体这类资源有个特殊规矩：浏览器取它的时候必须用匿名的跨域模式，无论字体放在自己的域还是别人的域上。所以预加载字体时也必须显式声明同样的模式，两边才能对上。

少写这一个属性的后果不是报错，而是浏览器会把同一个字体文件下载两次——预加载那次因为模式对不上被丢弃，真正渲染时再取一次。

224条里有101条少写了它，占45.1%。也就是说，将近一半的字体预加载不但没有加速，反而多花了一份流量。

为什么这个错这么普遍

因为它完全静默。页面照常渲染，字体照常显示，唯一的痕迹在开发者工具的网络面板里——同一个文件出现两行。而这个面板平时没人会盯着看。

顺带一提，缺少用途声明的只有1条。这说明大家都知道要写用途，只是不知道字体还有额外那条规矩。

两次快照隔了一段时间，这块配置动过吗？

前面一直在说这块配置没人管，这个说法需要一个直接的证据。手边正好有同一批站在两个不同时间点抓下来的首页快照，拿来比一遍就有答案。

121个站里111个一字未改

比对办法是把每个站的提示集合拿出来——类型、域名、用途三样组成一条指纹，排序之后整体比较。两次都抓到的站有121个。

结果是111个站的这块配置完全一致，占91.7%。有变化的只有10个站。

这个91.7%要跟另一件事放在一起看才有分量。同一批站上另一个长期没人管的字段，量出来是同一种形态：只要一个字段的更新没有挂在任何自动触发点上，它就会停在写下去的那一天不动。差别不在这个字段重不重要，在于有没有一个程序会在依赖变化时把它重写一遍。

这个数字要和别的东西对照才有意义。同一批站在这段时间里改过商品、改过首页banner、跑过活动，页面本身变化不小。而头部那十几行提示，九成以上一个字符都没动。

那10个变了的站，多半也不是有人去改它

变化的那10个站里，几乎都能看出是别的改动带来的连带效果：换了一个第三方服务，新服务的接入代码自带一行提示；或者升级了打包工具，构建生成的那批跟着重排。

真正意义上有人打开模板、盯着这几行、决定删掉某一条的，从这份数据里看不出任何痕迹。

不变本身不是坏事，坏在世界会变

要公平地说，一块配置长期不变常常是好事——说明它稳定、没人乱动。问题在于这块配置描述的不是自己，而是外部依赖。

你的分析工具从一个域名迁到另一个域名，你的字体从自托管换成第三方服务，你的评论插件被平台下架。这些事一件都不会来敲你模板的门。

顺着这些域名，能反推出这块配置是哪一年写的

这批提示里指向的域名，本身就是一份地层剖面。

指向那个老牌统计服务旧域的，多半写于新一代统计产品普及之前；指向某个已下架评论服务的，写于那个服务还在架上的年头；指向某家同意管理平台四个子域的，写于那次合规改造。每一条都能对应到一个具体的年份区间。

拿这个办法翻自己站的头部，往往能得到一个让人不太舒服的结论：这块配置的中位年龄，可能比你团队里一半人的司龄都长。

更实际的用处是排优先级——年代越久远的那几条，越可能已经失效，也越安全删。

空转一条到底要付多少钱？

这一节需要先说明边界：本文没有做端到端的加载速度对照实验，所以不会给出快了多少毫秒这种数字。下面只算能算清楚的部分。

字节成本，算得出来但不多

一行提示按标签加域名估算大约60到90个字符。中位数12条的站，这块占页面不到1KB。写了244条的那个站，粗算下来在15KB上下，压缩之后还会更小。

所以单看体积，这不是一个值得写文章的问题。真正的成本在别处。

连接槽位是有限的

提前建连这一类会真的发起网络动作：域名解析、传输层握手、加密握手，它比域名预解析多做的那两步正是它成本高的原因。浏览器在页面加载最忙的那几百毫秒里，能同时做的这类动作是有限的。

一条指向死域名的提示会占住一个位置，直到解析超时才释放。而这个位置本来可以用给真正马上要用的资源。浪费掉的不是字节，是首屏最稀缺的那段并发。

这也是为什么各家的建议里都强调提前建连要克制，通常给的参考上限是个位数。样本里超过这个量级的站不在少数。另外要留意协议层面对连接复用的规定：闲置的连接会被回收，提前太久建的连接到真要用时可能已经关了。

字体那101条的成本是实打实的一份流量

相比之下，字体预加载写错模式的代价很明确：同一个文件下载两次。一个中文字体子集动辄几十上百KB，翻倍就是实实在在的浪费，而且发生在首屏最要紧的时候。

还有一项成本不在浏览器里

最后一项成本落在人身上。一块没人敢动的配置会持续消耗后来者的判断力：每次改版都要问一遍这些还要不要，每次都问不出答案，于是每次都原样留下。

这类欠账的特点是单次成本极低、累计成本很高，而且永远排不进任何一次排期。

还有一个更隐蔽的连带影响：这块配置里指着的域名，会被安全审计和合规盘点当成你的外部依赖清单。一个早就不用的服务留在那儿，等于在自己的资产台账上白挂一条，答问卷的时候还要专门解释一遍。

被指得最多的那批第三方域，各自的空转率差在哪？

把所有第三方域按被多少个站声明过排个序，前二十名里空转率的差异非常大，而这个差异本身是有规律的。

平台自家的域几乎不空转

被57个站指着的那个电商平台内容分发域，空转数是0。被53个站指着的平台埋点域，空转数也是0。

原因很简单：这两条是平台默认模板自带的，而平台自己的资源必然会被加载。它们跟着平台的版本走，属于有人维护的那一类。

已经被新版取代的旧统计域，空转率最高

被17个站指着的那个老牌统计服务域，13个站空转，空转率76.5%。

这个数字背后是一次行业级的迁移：新一代的统计产品不再从那个域取资源，改走标签管理器那条路。迁移做完之后，绝大多数站没有回头删掉旧域名的提示。

作为对照，标签管理器那个域被27个站指着，只有8个空转，空转率29.6%。一新一旧，差了将近三倍。

字体服务的两个域，命运完全不同

字体服务通常需要声明两个域：一个取样式表，一个取字体文件。样本里前者被16个站指着，4个空转；后者同样16个站，12个空转。

这个差异有点意思。合理的解释是不少站把字体改成了自托管，样式表那一条因为还有别的用途留了下来，而字体文件那一条彻底失去了对象。

一个同意管理服务的四个域，7个站全部空转

还有一个更整齐的例子：某个隐私同意管理服务在样本里出现过四个不同的域，每个都被7个站声明，而且这7个站的这四条全部空转，一条不落。

四条一起进来、一起失效，说明它们是作为一整段代码被粘贴进模板的。卸载那个服务的时候，粘贴进去的那一段没有被完整地拿走。

规律可以总结成一句话

空转率低的域，共同点是它由某个还在运行的系统持续产出；空转率高的域，共同点是它由一次性的手工动作留下。判断一条提示会不会变成垃圾，看它是被写进去的还是被生成出来的。

再看几个空转为零的域，它们有个共同特征

榜单里空转数为零的还有几个：某个网页测试平台的域被11个站指着，零空转；某个评论应用的域被5个站指着，零空转；某个公共脚本分发网络被5个站指着，也是零空转；某个隐私合规平台的域被6个站指着，同样零空转。

它们的共同点不是名气，而是那个服务今天还在这些站上跑着。提示之所以没空转，不是因为有人维护提示，是因为没人需要维护——被指的东西还在原地。

反过来说，空转率是一个滞后指标：它量的不是你今天的配置质量，是你过去几年换过多少家供应商，以及每次换的时候有没有收尾。

还有一类容易被误判的：接口域

字体服务那两个域的对比里藏着一个方法论提醒：一个域名被声明了却没有资源加载，未必是废的，也可能是它只承载接口调用而不承载静态资源。

本文的软判据（全文搜索域名）就是为这类情况准备的。样本里452条没有资源加载的提示，有251条在页面文本里还能搜到，占55.5%——这一半多不能算废，只能算不确定。真正判定为空转的201条，是连字符串都找不到的那一批。

怎么在自己站上把空转的那几条挑出来？

这套检查不需要任何付费工具，一个人半小时能跑完一个站。

手工版：四步

第一步，打开首页源码，把头部所有资源提示那几行拷出来，按类型和域名整理成一张表。重复的先合并，记下重复次数。

第二步，打开开发者工具的网络面板，硬刷新一次页面，把实际发起请求的域名列出来。

第三步，两张表对照。出现在第一张表里、不出现在第二张表里的，就是候选空转项。

第四步，对每个候选项在源码里全文搜一次这个域名。搜得到说明它可能在某个脚本里被动态调用，先留着；搜不到就是确认空转。

批量版：把它接进构建

如果站不止一个，或者想每次上线都查一遍，做法是在构建产物上跑一段脚本：解析出所有提示的域名，再解析出所有资源地址的域名，做个差集。

这段脚本的核心逻辑不到三十行。把它挂在构建流程的末尾，差集非空就打印警告——不用让构建失败，警告足够了，因为动态调用的情况确实存在。

顺手要查的三件事

第一，字体预加载有没有写跨域模式。这一条最值钱，样本里45.1%的字体预加载栽在这儿。

第二，有没有同一个域既写预解析又写建连。有就删掉预解析那条。

第三，把所有提示的域名拿去做一次域名解析。解析不出来的直接删，没有任何风险。

开发者工具本身会替你报一部分

还有一个几乎零成本的办法：预加载了却没被用到的资源，浏览器会主动在控制台打一条警告。打开控制台看一眼首页，能免费捡到一批。

可惜提前建连和域名预解析这两类不会触发任何警告——而它们恰恰是空转率最高的两类。这也解释了为什么这块问题能积攒这么久。

这件事归谁管，是它长期没人做的根本原因

值得说一句组织层面的事。这块配置卡在一个尴尬的位置：它写在前端模板里，归前端；它的收益体现在加载体验和搜索表现上，归SEO或者增长；而它变废的原因是某个第三方服务被换掉了，那件事归市场或者数据团队。

三方都碰得到它，三方都不觉得它是自己的活。于是它成了那种谁都能改、谁都不改的东西。

破局的办法不是开会定责任人，而是把判断变成机器能做的事：把差集检查塞进构建流程，让它在每次上线时自己喊一嗓子。一件需要有人记得的事，迟早会没人记得；一件程序每次都会做的事，才可能长期正确。

这也正是那1864条构建生成的提示零空转的全部秘密——不是它们的作者更有责任心，是它们根本不需要作者。

删之前要确认什么，删错了会怎样？

体检报告最怕的就是按报告一删了之。这一节说清楚哪些能直接删、哪些要先确认。

可以闭着眼睛删的三类

第一类，域名解析不出来的。它已经不可能提供任何资源，留着只有害处。

第二类，同一域名重复出现的多余那几条。保留一条即可。

第三类，同一域名既有预解析又有建连时，删掉预解析那条。

要先确认再删的两类

第一类是页面文本里搜得到但没有资源加载的。这多半意味着某个脚本会在特定条件下才去请求它——比如用户点了某个按钮才加载的聊天窗，或者只在特定地区才启用的支付方式。这类提示是有意义的，删掉会让那条路径变慢。

确认办法是把那几个交互都点一遍，看网络面板里会不会冒出这个域名。

第二类是首屏之后才用到的域名。提前建连的价值本来就在于覆盖还没发生的请求，所以看不到资源不等于没用。判断依据是滚动到底、等页面完全静止之后再看一次网络面板。

删错了会发生什么

好消息是这类改动的破坏面很小：删掉一条提示不会让任何功能失效，最坏的结果是那个资源第一次加载时慢几十到几百毫秒。

坏消息是这个后果不会立刻显现，也很难被归因。所以稳妥的顺序是先删死域名和重复项——这两类零风险，往往就能砍掉大半——再花时间确认剩下的。

删完怎么验证没删错

验证不需要专业工具，两步就够。

第一步，改完之后把首页、一个分类页、一个商品页各走一遍，把主要交互都点开——搜索框、加购、切换币种、打开客服窗口。全程开着网络面板，看有没有请求因为找不到连接而卡住。

第二步，用性能面板各跑一次改前改后，重点看最大内容渲染那个数字有没有变差。删对了它应该微微变好或者不变；如果明显变差，说明删掉了一条真在用的。

这两步加起来二十分钟。相比之下，把这块配置继续放着不管的成本是每年都要重新纠结一次。

如果站上有灰度发布的能力，还可以更稳一点：先把改动放给一小部分流量，观察一两天真实用户的加载指标再全量。这类改动的信号很弱，小流量下未必看得出差别，但至少能确认没有变差。

最后提醒一句，改完记得把变更写进记录——哪一行、什么时候删的、当时的理由是什么。这几句话的价值在半年后才会显现：那时候有人问起为什么头部比记忆里干净，你能答得上来，而不是又加回去一遍。

删完之后要留一道闸

和所有这类清理一样，只删一次的结果是过一年又长回来。要让它别复发，得在流程里留个东西。

最省事的是在构建脚本里加那段差集检查，输出到构建日志。稍微认真一点的做法是给这块配置加一段注释，写清楚每一行是哪年为什么加的、什么条件下可以删。一行没人说得清来历的配置，注定会被下一个人原样留下。

常见问题解答

提前建连和域名预解析，该用哪个？

如果确定马上要从那个域取东西，用提前建连，它把域名解析和两次握手都提前做了。如果只是有可能用到，或者数量比较多，用域名预解析，它成本低得多。两个同时写同一个域是冗余，样本里74条属于这种情况，涉及30个站，建议只留建连那条。需要注意提前建连是有真实成本的动作，各家建议的数量上限都在个位数。

写多少条提前建连算多？

常见的参考上限是四到六条。样本里122个站的中位数是12条，已经超了；写得最多的站有244条，其中230条是重复。去重之后多数站落在十条上下，仍然偏多。判断的办法不是数条数，而是问每一条对应的资源是不是首屏就要用——不是的话它就在跟首屏抢连接。

预加载字体为什么一定要写跨域属性？

因为浏览器取字体文件时一律用匿名跨域模式，不管字体在不在自己的域上。预加载时如果不声明同样的模式，两边的缓存键对不上，预加载那一份会被丢弃，渲染时再下载一次。样本里224条字体预加载有101条少写了它，占45.1%。这个错完全静默，只有在开发者工具的网络面板里能看到同一个文件出现两行。

页面里搜不到这个域名，就一定能删吗？

不一定，但风险很低。要先排除两种情况：一是某个脚本在特定交互之后才去请求它，二是首屏之后才用到。前者把主要交互点一遍就能验，后者滚到底等页面静止再看一次网络面板。两条都排除之后可以删。就算删错了，后果也只是那个资源第一次加载慢一点，不会有功能损坏。

这些提示会影响搜索排名吗？

不直接影响。它影响的是页面加载体验，而加载体验是排名信号之一。所以链路是间接的：空转的提示占住首屏的连接并发，真正要用的资源排在后面，首屏渲染变慢，体验指标变差。反过来说，删掉几条死掉的提示不会让排名立刻变好，它属于那种攒起来才有意义的小改动。

为什么打包工具生成的那批不会空转？

因为它每次构建都被完整重新生成。工具知道这次产出了哪些代码块、哪个页面会用到哪一块，据此写出对应的提示。依赖变了，下次构建时提示自动跟着变。样本里这两类一共1864条，空转数是0。手写进模板的那两类676条里空转197条。差别不在写的人认不认真，在于有没有一个程序在替他持续重写。

能不能干脆全删了？

不建议。用对的时候这些提示确实有效，尤其是首屏字体和关键第三方资源。合理的目标不是清零，是让每一条都对应一个真实存在、且首屏就要用的资源。样本里53个站做到了完全没有空转，说明这个目标并不苛刻。

多久查一次合适？

换第三方服务、换字体方案、换分析工具、做改版，这四件事之后各查一次，比定期巡检有用得多——因为空转恰恰是在这些时刻产生的。如果实在要定个周期，半年一次足够。更好的做法是把差集检查接进构建流程，让它每次上线自己跑。

权威参考资料