27 个首页 650 条资源提示：preconnect 有 49 条，三个站在 preconnect 自己

实测 · 2026-08-24 · 27 个首页 · 单次抓取 · 只数 link rel 提示

样本 / 口径：2026-08-15 以来一直在用的那批 30 个站，2026-08-24 当天每个首页抓一次，浏览器 UA。只读下发的 HTML，把 rel 为 preconnect、dns-prefetch、preload、modulepreload、prefetch、prerender 的 <link> 全记下来，连同 href、as，以及 crossorigin 属性写没写。

27 个首页一共数出 650 条资源提示。中位每站 5 条，最多的一个站 263 条。preconnect 占其中 49 条、出现在 19 个站上，而 dns-prefetch 只有 5 个站还在用。三个站一条提示都没有，另有三个站在 preconnect 自己的源站。

怎么测的

每站一次请求，不渲染、不重试。纳入规则跑数前写死：状态 200、响应体不小于 10,000 字节、含 <body。30 个里 3 个没过 —— stackoverflow.com 与 medium.com 返回 403，www.reddit.com 返回 8,393 字节空壳 —— 剩 27 个。

页面加载后由脚本插进去的提示我们看不见，所以这里每个数字都是下限，不是总数。我们也没测这些提示到底让哪个页面变快了 —— 那要真实网络下的连接计时，而这次是每站一次抓取。

650 条提示，六个关键字里有两个一次都没出现

这个分布不能用平均数说话。均值 24.1、中位 5，因为一个站自己扛了四成样本。

linear.app 一家 263 条，其中 258 条是它自己 JavaScript 分包的 modulepreload。第二名 github.com 80 条，第三名 www.nytimes.com 70 条。另一头 www.canva.com、www.netlify.com、news.ycombinator.com 一条都没有。

三个站在 preconnect 自己

stripe.com、www.notion.com、www.bbc.com 都发了 <link rel="preconnect" href="/" crossorigin="anonymous">。指的就是浏览器此刻正在通话的那个源站。MDN 的 preconnect 参考页（2026-08-24 读）说得很直接：「It has no benefit on same-origin requests because the connection is already open.」

三条标签都带 data-next-font 属性，也就是说没人手写过它，是框架发出来的。这一点值得知道，因为它改变了该怎么处理：你自己的模板里没有可改的东西，去翻也翻不出什么。

一条资源提示是在承诺「马上有个请求要来」。请求没来，这条提示就是白占了一个连接位。

dns-prefetch 基本退场了，位置被 preconnect 顶掉

还在用 dns-prefetch 的只有五个站：github.com、railway.com、stripe.com、techcrunch.com、www.theverge.com。其中 stripe.com 和 github.com 对同一批主机两种提示都写了，分别是 4 个和 2 个主机 —— 那是给老浏览器留的降级写法，不是写错了。

MDN 解释过这两者为什么要分开：「If a page needs to make connections to many third-party domains, preconnecting them all can be counterproductive. The <link rel="preconnect"> hint is best used for only the most critical connections. For the others, just use <link rel="dns-prefetch"> to save time on the first step — the DNS lookup.」

按这句话读，19 比 5 这个比例是反的。我们不知道这里面有没有哪个站真的因此更慢，这次没有做连接计时。

那 169 条 preload 到底指向什么

169 条里没有一条漏写 as。这正是 MDN 点名的那种失败写法 —— as 决定浏览器用什么优先级、发什么 Accept 头、套哪条内容安全策略。

字体那一行本来是我们最预期会一片狼藉的。MDN 写着「font and fetch preloading requires the crossorigin attribute to be set」，字体 preload 少了它会另开一条用不上的连接。这批样本里 29 条一条不落全写了。

这个答案我们第一遍是搞错的。解析器按值去读 crossorigin，而 crossorigin 单写和 crossorigin="" 都是合法的匿名模式写法，于是九条正确的标签被判成九条错的。改成判属性在不在才对。自己写标记检查脚本的话，布尔属性就是最容易翻车的地方。

这对你意味着什么

资源提示加起来很便宜，也因此最容易忘了删。样本里有四处重复：www.framer.com 对 fonts.gstatic.com 的 preconnect 写了两遍，www.shopify.com 对 cdn.shopify.com 同样，www.nytimes.com 和 linear.app 各有 preload 重复。

• preconnect 只留给关键路径上那两三个主机，其余用 dns-prefetch。
• 每条 preload 都写 as，字体那几条一律补 crossorigin。
• 别 preconnect 自己的源站。那条连接早就开着了。
• 别预加载页面未必会用的东西。用不上的 preload 就是一次白发的请求。

提示是最后才调的一环，不是第一环。文档本身就慢的话，这些一条都救不回来 —— 同一批站的网站速度实测 是该先看的那个数，想看整条链路而不是单个响应头，诊断路径从这里开始。

常见问题

你们是怎么测的

2026-08-24 当天每个首页一次请求，浏览器 UA，不执行 JavaScript。解析下发 HTML 里的每个 <link>，保留六种提示型 rel，记下 href、as，以及 crossorigin 和 imagesrcset 这两个属性写没写。

preconnect 和 dns-prefetch 差在哪

dns-prefetch 只解析域名。preconnect 解析完还把 TCP 和 TLS 握手一起做掉。后者省的时间更多，代价是占一个连接，所以 MDN 建议只留给最关键的几个主机。

preconnect 对 SEO 有用吗

单独看没有，也没有任何一份文档这么说过。它影响的是浏览器多快能开始取子资源，这会体现在真实用户性能数据里，而那是一个很小的排名输入。中间隔了三层，我们宁可把它写开，也不压缩成一句断言。

为什么有 23 条图片 preload 没有 href

它们用的是 imagesrcset 加 imagesizes，这是图片预加载的响应式写法。那是正确的标记，不是漏了属性。我们的计数把它们算作「没有单一 URL 目标的图片预加载」。图片该不该一开始就加载是另一个问题，见 1,677 张首页图片的 loading lazy 实测。