页面要快，瓶颈常常不在服务器，而在”建立连接”和”等资源整合”上。浏览器得先和 CDN、字体服务、第三方脚本的域名握手建连，这一来一回就是上百毫秒。资源提示（Resource Hints）就是提前告诉浏览器”待会要连谁”，把等待藏到空闲里。
preconnect、dns-prefetch、preload、prefetch 四个指令各管一段，用对了能明显压低 LCP 和整体时延。这篇文章讲清各自适用场景和坑。它们对抓取效率也有间接帮助，相关思路可结合抓取预算优化来看。
快速结论
- 资源提示四类：preconnect、dns-prefetch、preload、prefetch，各管建连/解析/优先/预取。
- preconnect 用于关键第三方域（CDN、字体），提前完成 TCP+TLS 握手。
- preload 只给”本页必用且阻塞渲染”的资源，滥发反而抢带宽。
- 验证靠 DevTools 的 Timing 和字段数据，看建连时间是否真的下降。
什么是资源提示
资源提示是一组 指令，不改变页面内容，只给浏览器”提前量”。默认浏览器是”用到才连”，而提示让它”猜到要用就先连”，从而把建连耗时从关键路径上挪走，用户感知的加载更快。
四类里，dns-prefetch 最轻（只解析域名），preconnect 更重（连完 DNS+TCP+TLS），preload 是”立刻下载指定资源”，prefetch 是”闲时预取可能用到的下一资源”。强度递增，代价也递增，按需取用。整体框架见技术SEO 实战手册。
preconnect 用法
preconnect 适合”马上要用的跨域关键资源”，比如字体从 fonts.gstatic.com 加载、主图在独立 CDN。写 ，浏览器会提前和这个域完成握手，等真正请求资源时就省了那一段延迟。
注意两点：一是别 preconnect 太多域，浏览器并发连接有限，列十个反而互相挤占；二是 preconnect 只建连不下载，若想连完直接拿资源，配合 preload 更稳。通常 2-4 个最关键的第三方域足够。
preload 与 prefetch 的区别
preload 是”本页渲染必须用、且想立刻拿到”的资源（如首屏关键 CSS、LCP 图片），浏览器会高优先级下载，避免被其他请求排在后面。它作用于当前页，用错会拖慢真正重要的东西。
prefetch 则相反，是”下一页或空闲时可能用到”的资源，浏览器在低优先级、空闲带宽下偷偷下载，等用户真跳过去时已就绪。典型用法是预取列表页的下一页、或文章底部的”猜你想看”。下表对比四类。
图：资源提示 核心要点（运营GO 整理）
| 指令 | 作用 | 优先级 |
|---|---|---|
| dns-prefetch | 仅解析域名 | 低 |
| preconnect | 建连(含 TLS) | 中 |
| preload | 立即下载本页资源 | 高 |
| prefetch | 闲时预取下一资源 | 最低 |
对 Core Web Vitals 的帮助
preconnect 把第三方握手藏起来，直接压低 LCP 和 TTFB；preload 确保首屏关键资源不被排队耽误，同样利好 LCP。它们不解决图片体积问题，但能消除”连接等待”这块常被忽略的时延，叠加图片优化效果更明显。
但要清醒：资源提示是”减法”优化，省的是几十到一百多毫秒，救不了体积爆炸的页面。先把图片、渲染阻塞脚本这些大头处理了，再上资源提示做精细打磨，顺序错了事倍功半。
常见误用
误用一：preconnect 列了十几个域，浏览器连接池被打满，反倒变慢。误用二：preload 一个用不上的资源，白白占带宽还报警”preload 未使用”。误用三：把 prefetch 当 preload 用，关键资源被排到闲时才下。
误用四：提示指向已合并到主域的资源，跨域建连纯属多余。修法是先理清本页真实的关键第三方域和关键资源，再精准下指令，加一条就验证一条，别一次性铺满然后猜哪条有用。
怎么验证生效
在 DevTools 的 Network 面板看资源 Timing，对比加提示前后”Connecting””TLS”耗时是否下降；Waterfall 里关键资源是否更早开始下载。字段数据看 GSC 的 Core Web Vitals 报告，LCP 是否随改动改善。
验证别只看实验室数据，实验室快不代表真实用户快。把资源提示纳入发版前后对比，关注真实用户的 LCP 百分位变化，确认优化真的落到字段指标上，而不是只在本地测速漂亮。
和 CWV 其他项的关系
资源提示主要利好 LCP，但对 CLS（累积布局偏移）和 INP（交互延迟）也有间接帮助：连接和下载更快，主内容更早稳定，后续布局抖动窗口更短；脚本更早就位，交互响应也更跟手。
不过别指望它单枪匹马救活三项。CLS 要靠给媒体预留尺寸、INP 要靠拆分长任务，各管一摊。资源提示是”加速”那一环，和其余两项的优化是正交互补，组合起来才凑齐合格的 Core Web Vitals。
指令冲突怎么处理
preload 和 prefetch 同时指向争抢带宽时，preload 高优先级会压过 prefetch，这是预期行为；真正要防的是 preconnect 太多导致连接池挤占，以及 preload 了一个根本用不到的资源还报警。
处理原则是”少而准”：每个提示都对应一个真实瓶颈，加完用字段数据验证收益，没收益的就删。提示不是越多越好，堆满反而让浏览器在无效预连上浪费资源，违背了省时间的初衷。
移动端特别提醒
移动网络延迟高、连接更贵，preconnect 的收益比桌面更明显，但移动浏览器对并发连接更克制，所以移动端更要”少而准”，别把桌面那套十几个域照搬到手机，反而拖慢。
另一点：移动弱网下 preload 错资源更伤，带宽被占、关键内容反而更慢。移动视图要对提示做裁剪，只保留真正跨域关键的两三个域，其余交给桌面策略，别一刀切成同样的清单。
下一步行动清单
- 列出本页最关键的 2-4 个跨域（CDN、字体），加 preconnect。
- 对首屏阻塞资源用 preload，且仅限本页必用项。
- 给”下一页”类资源加 prefetch，利用空闲带宽。
- 用 DevTools Timing 和 GSC 字段数据验证建连耗时下降。
- 发版前后对比真实用户 LCP，确认优化落到字段指标。
