2026 年 8 月我们接手一个站，head 里写了九条 preload，测完发现只有三条真正被首屏用到。剩下的不但没帮忙，还抢了 LCP 图片的带宽，首屏反而慢了 200 毫秒。资源提示不是越多越好。
三种提示各管什么
dns-prefetch 只做 DNS 解析，最轻，适合那些一定会请求、但不急的第三方域。
preconnect 多做一步，把 TCP 连接和 TLS 握手也提前完成，成本高一点，适合关键第三方域，比如字体、CDN、支付。
preload 直接下载指定资源，优先级最高，会和其他关键资源抢带宽，所以只该给首屏必需的东西。
什么该 preload
LCP 那张图。它是首屏最大的元素，提前下载能直接改善指标。
关键字体。字体藏在 CSS 里发现得晚，preload 能省一个来回，但要带 crossorigin。
关键 CSS，如果它放在外部文件里，可以 preload 之后切换成样式表。
我们通常控制在三个以内。超过三个，就要问一句：这些真的都是首屏必需的吗。
用错的三种情况
第一种，preload 了没用上的资源。Chrome 会在控制台警告“资源被预加载但未在几秒内使用”，看到这条警告就该删。
第二种，crossorigin 不匹配。字体 preload 不带 crossorigin，浏览器会当成另一个请求，等于下载两次，比不 preload 还慢。
第三种，给非首屏图片做 preload。用户在首屏根本看不到，提前下载纯属浪费。
怎么验证
DevTools 网络面板有一列优先级，看 preload 的资源是不是真的排在前面，有没有把 LCP 图挤下去。
再看瀑布图。preload 生效的话，关键资源的请求起点会提前到和 HTML 解析并行；没生效的话，它还是排在一堆请求后面。
最后对比改前改后两次的 LCP。没有改善就说明用错了，别留着。
一次真实的清理
2026 年 6 月我们查另一个站的 preload，九条里有六条是产品经理要求加的，理由是重要。
逐条看：两张大图不在首屏、一个统计脚本、一个客服组件、一个字体子集其实没用到、一个视频预加载了八兆。
删掉六条、保留三条之后，首屏 LCP 从 2.9 秒降到 2.4 秒。加的时候每个人都说重要，删的时候没人反对。
怎么跟团队解释
资源提示的效果很难用业务语言描述。我们的说法是：它只影响首屏的等待时间，不影响功能。
所以争议最小，改起来也安全。上线前测一次，有改善就留，没改善就删，不需要开会讨论。
一个判断
资源提示是微调工具，不是万能药。它能省一两百毫秒，前提是用对地方。
网络优化的顺序应该是：先砍掉不必要的资源，再优化关键路径，最后才用提示做微调。
顺序反过来，先加一堆 preload，只会让本来就拥挤的首屏更乱。
元析智能
为软件公司做 SEO 和 GEO 优化