dns-prefetch、preconnect、preload、prefetch：目录站这四个标签该怎么用，用反了更慢
d
目录站的首页天生是「资源最多」的一类页面：几十上百个条目卡片、一堆外站 favicon、可能还有 CDN 上的缩略图和第三方统计。这种情况下，很多人会听说「加资源提示能提速」，于是一口气把四个标签全加上，每个域名来一份。
结果往往是页面没变快，DevTools 里倒多了一堆低优先级请求。原因很简单：这四个标签提前的是完全不同的四件事，混着用等于让浏览器同时去做一堆它本来会按优先级排好的事。
图片来源：网络，版权归原作者所有，侵权请联系删除
四个标签，处在网络流程的四个阶段
| 标签 | 提前做了什么 | 代价 | 该用在谁身上 |
|---|---|---|---|
| dns-prefetch | 只做 DNS 解析 | 几乎为零 | 次要的第三方域名 |
| preconnect | DNS + TCP + TLS 握手 | 占连接与 CPU | 两三个真正关键的源 |
| preload | 立刻以高优先级下载某个资源 | 抢带宽 | 当前页的关键资源 |
| prefetch | 空闲时低优先级拉取 | 用户没跳就白费 | 下一页要用的东西 |
理解这一张表，剩下的都是推论。
preconnect 只给最关键的两三个源
preconnect 换来的是省掉一整套握手，通常能省 100 到 300 毫秒。但它打开的是一条真实连接，浏览器对每个源的并发连接数是有限的（常见是 6 条），全局连接池也有上限。给十个源各来一个 preconnect，等于把连接池先占掉一半，真正要用的那个源反而排队。
目录站上真正值得 preconnect 的，一般只有两个：缩略图所在的 CDN 域，和字体所在的域。第三方统计脚本那类「晚点加载也无所谓」的东西，用 dns-prefetch 就够了。
字体这里有个老坑：加载 Google Fonts 时，CSS 来自 fonts.googleapis.com，字体文件来自 fonts.gstatic.com，是两个不同的源，而且字体走 CORS。少了 crossorigin，浏览器会再开一条连接，钱花了没办成事：
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>preload 是给「解析器发现得太晚」的关键资源准备的
浏览器有个预加载扫描器，会提前扫 HTML 里的 img、script 标签。已经在 HTML 里、位置靠前的资源，其实不需要 preload——扫描器早就看到了。真正需要它的是两类：藏在 CSS 里的（@import 的样式、背景图、字体），和由 JS 决定的。
两个硬性要求：as 属性必填，写错了或者不写，浏览器可能下载两次；字体必须带 crossorigin，哪怕文件就在你自己域名上。
<link rel="preload" as="font" type="font/woff2"
href="/fonts/main.woff2" crossorigin>
<link rel="preload" as="image" href="/img/hero.webp"
imagesrcset="/img/hero-800.webp 800w, /img/hero-1200.webp 1200w"
imagesizes="100vw" fetchpriority="high">preload 最典型的滥用是一次性 preload 七八个东西。它们全都是高优先级，结果就是互相抢带宽，LCP 反而变差。Chrome 控制台会直接给你一句提示：某个资源用 link preload 预载了，但几秒内没被用到。看到这句就删掉它。
prefetch 是给下一页的，别拿来救当前页
prefetch 是低优先级、空闲时执行、为下一次导航服务的。拿它去加载当前页的 LCP 图，属于用错了工具——那张图要在首屏就出现，该用的是 preload 加 fetchpriority。
目录站用得上 prefetch 的地方其实很明确：列表页第一页预取第二页，条目页预取同分类的下一个条目。别全站无差别开，用不上的那部分就是纯浪费流量，对移动端用户尤其不友好。如果现在已经在用 Speculation Rules，文档级的预取和预渲染交给它更合适，规则、急切程度和上限都能写清楚。
目录站的实际清单
- 缩略图 CDN：一个 preconnect。只要一个，别给每个 CDN 子域都加。
- 字体：preload 加 crossorigin，或者干脆用系统字体栈。中文字体子集化之后体积能降一个量级，比 preload 有效得多。
- LCP 图：preload 加 fetchpriority="high"。只标一张，别把所有卡片图都标上。
- 外站 favicon 直引：不要为它们 preconnect。几十个外域各开一条连接，是最典型的「加了反而更慢」。
- 第三方统计、客服挂件：dns-prefetch 就够了。它们本来就不在关键路径上。
加完之后怎么确认有用
资源提示这类优化，最容易自欺欺人——加了之后感觉快了，其实没测过。三步就能验：
第一步，DevTools 的 Network 面板，看目标资源的 Priority 和 Start Time，确认它确实被提前了。第二步，跑 Lighthouse 或 PageSpeed Insights，看「预连接到必要来源」「预加载关键请求」两条有没有变化。第三步，用限速的移动配置再测一遍，别只在本地局域网里看。
还有一句要提醒：资源提示改变的是「发现时机」，改变不了服务端有多慢。一个 2 秒 TTFB 的接口，加 preconnect 之后还是 2 秒。这一层的问题要去服务端和缓存上解决。