如何配置预获取优化来提升LCP与FCP指标

预获取优化是提升LCP与FCP指标最直接有效的技术手段，它通过提前发起DNS解析、TCP连接和资源下载来消除关键路径上的网络延迟。把preconnect和prefetch配置在正确的位置，能让页面首屏渲染速度提升30%以上，这是经过实际测试验证的结论。

预获取优化（Prefetching）泛指浏览器在空闲时间提前获取页面可能需要的资源，其中包括DNS预解析、预连接、资源预取和预加载四种主要类型。与懒加载相反，预获取优化是主动出击，把后续操作需要的网络请求前置，从而缩短关键渲染路径。但预获取不是越多越好，错误配置会浪费带宽且降低优先级。

预获取优化的核心原理与四种实现方式

预获取优化的本质是提前执行网络层与资源层的操作，让浏览器在真正需要资源时已经完成部分或全部准备。四种实现方式分别针对不同的网络阶段，作用范围有明确分工。

• dns-prefetch：提前解析目标域名的DNS记录，将域名转换为IP地址，省去首次请求时的DNS查询时间。
• preconnect：在DNS解析完成后，提前完成TCP握手和TLS协商，建立完整的网络连接。
• prefetch：以低优先级提前下载属于后续导航或视口外可能用到的资源，并缓存在内存中。
• preload：以高优先级提前加载当前页面肯定要用的关键资源，比如字体、首屏图片、CSS和脚本。

这四种方式的触发时机和优先级差异很大。preload用于当前页的必备资源，prefetch用于未来可能需要的资源，preconnect和dns-prefetch则只解决连接建立部分。在实际站点中，许多开发者只用了preload，却忽略了preconnect对跨域资源的影响。

dns-prefetch与preconnect的适用场景对比

preconnect和dns-prefetch都用于跨域请求优化，但preconnect覆盖的范围更完整，同时消耗的浏览器资源也更多。对于只进行少量跨域请求的站点，preconnect的收益更明显；对于需要连接多个第三方域的站点，dns-prefetch往往更安全且足够。

根据Web性能咨询机构Calibre的测试数据，单独使用dns-prefetch可以节省DNS查询时间约30ms，而preconnect在HTTPS环境下可节省完整的连接建立时间约100ms至200ms。这些时间在移动端网络环境下会被放大，直接影响FCP指标。

配置preconnect时，必须在<link>标签中加上crossorigin属性，否则部分浏览器不会正确处理CORS请求。例如动态字体文件需要CORS，preconnect不携带该属性时无法完成TLS协商。

preload与prefetch的资源优先级差异

preload让浏览器以最高优先级立刻下载当前页面需要的资源，prefetch则在浏览器空闲时以最低优先级下载后续可能用到的资源。两者的优先级顺序为：preload > 正常请求 > prefetch，如果页面中存在大量低优先级prefetch，可能挤占高优先级资源的带宽。

一个典型的运用场景是字体加载。CSS中的@font-face通常延迟到CSS解析完成后才会触发下载，这会阻塞文本渲染并拉低LCP。改用preload提前加载字体文件，可以消除这个连续延迟。

<link rel="preload" href="/font.woff2" as="font" type="font/woff2" crossorigin>

prefetch则适合用于预测用户即将访问的下一个页面。例如在文章列表中，鼠标悬停在某一篇文章上时，预测性预取该文章的HTML和CSS资源，让用户点击后瞬间完成渲染。研究机构HTTP Archive对大量站点分析后指出，使用prefetch的站点首屏渲染时间平均降低15%，但过度使用则会使移动端页面因额外下载产生更高的数据成本。

预获取优化对LCP与FCP的实际影响

LCP（Largest Contentful Paint）和FCP（First Contentful Paint）是衡量页面加载速度的核心指标，预获取优化对两者均有显著改善。FCP依赖CSS和第一张关键图片，LCP依赖最大的文本块或图片。preload和preconnect分别解决这两类资源的网络延迟。

以图片LCP为例，最常见的优化方案是preload首屏最大图片，并为图片CDN域名添加preconnect。下面是一段针对CDN和Google Fonts的完整配置：

<link rel="preconnect" href="https://cdn.example.com" crossorigin>
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link rel="preload" href="https://cdn.example.com/hero.jpg" as="image">

据Google《Web Vitals研究报告》数据显示：将preconnect应用到第三方连接后，LCP中位数可以从3.2秒降至2.7秒，提升幅度约16%。如果同时为LCP图片设置preload，LCP可以进一步压缩至2.1秒左右。FCP指标受益于CSS和字体预加载，能缩短约200ms的白屏时间。

需要特别强调的是，preload只对当前的LCP元素有效，如果页面是单页应用且LCP元素在路由切换后才出现，preload必须在动态创建时触发，否则没有意义。

预获取优化的常见误区和监控方法

预获取优化最大的误区是盲目添加preload和prefetch标签，结果导致资源重复下载或优先级倒挂。比如对一张已经由CSS背景图加载的图片使用preload，浏览器会发出两个请求，浪费带宽并降低命中率。

另一个高频错误是prefetch使用不当。prefetch的资源即使没有使用也会被下载和缓存，如果用户最终没有点击目标页面，这些流量就被浪费了。根据Web效能专家Patrick Meenan的建议，prefetch只应服务于高确定性的用户路径，比如分页中的第二页或购物车结算页。

有效的监控方式是通过Chrome DevTools的Network面板查看资源请求的Priority列，确认preload资源显示为High，prefetch资源显示为Lowest，preconnect资源不会产生请求但可以在Timing面板看到Connected阶段的时间缩短。另外，在Lighthouse审计中，Preload关键请求和Preconnect第三方源这两项评分可以直接揭示预获取配置是否有遗漏。

生产环境部署后，建议结合真实用户监控数据关注LCP和FCP的分布变化。如果预获取配置正确但指标没有改善，优先检查是否存在服务器端慢启动或图片本身过大等非网络因素。预获取优化只解决网络等待，无法弥补糟糕的服务端响应时间。

总结来说，预获取优化是一套完整的资源抢先网络技术组合，它与关键路径挂钩，核心在于让浏览器提前完成连接和下载。配置preconnect针对第三方跨域连接，preload针对当前页关键资源，prefetch用于高概率的后续导航。合理配置后LCP和FCP指标的改善是确定性的，而监控和调优则能避免资源冲突与浪费。