LINK标签预加载资源技巧分享

本文深入解析了HTML中``资源预加载机制的核心原理与实践要点，揭示其缓存行为并不由标签本身决定，而是依赖浏览器网络栈的临时托管及服务端响应头（如`Cache-Control`）的实际配置；文章澄清了“prefetch cache”并非独立缓存类型，因此不会出现在DevTools的Memory/Disk Cache面板中，需通过Network面板中`(prefetch cache)`状态、`purpose: prefetch`请求头及极短TTFB等指标验证实效性，并强调只有配合合理的服务端缓存策略（如`public, max-age=31536000, immutable`）才能让预取资源真正进入磁盘或内存缓存；同时对比指出`prefetch`与`preload`在目标场景、优先级、缓存保障和性能影响上的本质差异，警示开发者避免滥用——尤其在移动端，不当预取反而会挤占带宽、拖慢首屏，得不偿失。

prefetch 资源到底缓存在哪儿？

浏览器对 的缓存行为没有强制标准，它不走常规的 HTTP 缓存（Cache-Control、ETag 等）主流程，而是由浏览器内部网络栈（net-stack）临时托管。Chrome 当前（2026 年）仍基本遵循 Addy Osmani 早年指出的规则：prefetch 请求会在网络层缓存至少 5 分钟，但前提是资源本身允许被缓存（即响应头未设 no-store 或 no-cache）。若服务端返回 Cache-Control: no-store，即使 prefetch 触发了，也不会进入可复用缓存，下次访问仍会重新请求。

为什么 Network 面板看不到 “prefetch cache”？

因为这不是一个独立缓存类型，它不显示在 Memory Cache 或 Disk Cache 标签页里。验证是否生效，应关注两点：

• 在 Chrome DevTools 的 Network 面板中筛选 JS 或 Document，找状态为 (prefetch cache) 的条目（仅当该资源被后续导航真正使用时才出现）
• 更可靠的判断方式：打开 Network → 点击某个 prefetch 条目 → 查看 Headers 里的 Request Headers 是否含 purpose: prefetch
• 若资源被复用，Waterfall 中的 Waiting (TTFB) 会极短（接近 0ms），且 Size 显示为 from disk cache 或 from memory cache（取决于实际存储位置）

如何让 prefetch 资源真正进磁盘缓存？

关键不在 标签本身，而在服务端响应头配置。必须确保目标资源返回合理的缓存策略：

• 静态 JS/CSS/HTML 文件建议设：Cache-Control: public, max-age=31536000, immutable
• 带版本哈希的资源（如 app.a1b2c3.js）天然适合 long-term caching
• 避免对 prefetch 目标资源返回 no-cache、no-store 或 max-age=0
• 注意：即使加了 as="script"，若响应头禁止缓存，prefetch 也白做

prefetch 和 preload 在缓存行为上根本不同

preload 是为当前页面服务，加载后至少进内存缓存，且优先级高、立即触发；prefetch 是为未来页面准备，优先级最低、延迟执行，且缓存与否高度依赖服务端响应头和浏览器空闲状态。滥用 prefetch（比如对首页首屏资源也写 prefetch）不仅不会加速，反而可能挤占带宽、延迟关键资源下载。移动端尤其明显——4G 网络下 prefetch 多余请求容易拖慢首屏渲染。

好了，本文到此结束，带大家了解了《LINK标签预加载资源技巧分享》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！