HTML怎么做预加载prefetch_html prefetch预加载资源方法【从零开始】

prefetch：一把需要精准使用的性能优化“手术刀”

首先，我们必须明确一个核心概念：prefetch 并非用于加速当前页面加载的工具。它的核心机制是，在当前页面完全加载完成后，利用浏览器的空闲时间，以最低优先级去获取用户接下来“可能”访问的资源，并将其存入缓存。它非常适合用于单页应用（SPA）首页预取用户中心的JS模块，或者电商列表页预取几个高点击率商品的详情页资源。但请务必记住：prefetch 无法解决首屏加载的性能瓶颈问题。

这里必须划一个重点：滥用 prefetch 不仅会浪费宝贵的带宽、污染浏览器缓存，甚至可能干扰真实的用户行为数据分析。 它是一把需要精准使用的手术刀，而非一把可以随意挥舞的万能钥匙。

prefetch 的本质与适用场景

简单来说，prefetch 是浏览器在页面触发 onload 事件后，在空闲时段发起的一种低优先级网络请求。它的目标非常明确：为后续的页面跳转（例如用户点击某个链接）提前准备好资源，并存入HTTP缓存。但浏览器对此不作任何保证——如果用户开启了省流模式、网络环境较差（如2G），或者设备内存紧张，浏览器会直接放弃这些预取任务。

• 典型应用场景：在单页面应用（SPA）中，于首页预取用户中心页面对应的 user-center.chunk.js；或者在电商列表页，仅预取点击率最高的2到3个商品详情页所需的JS和CSS文件。
• 它不能解决什么：首屏加载速度。因为其请求发起时机过晚，对于LCP（最大内容绘制）和FCP（首次内容绘制）等关键首屏性能指标几乎没有提升作用。
• 它不适合加载什么：关键字体、首屏核心图片、阻塞渲染的CSS。这些关键渲染路径上的资源必须使用 preload，否则你依然会面临字体闪失（FOIT）或恼人的布局抖动问题。
• 一个严格的限制：同源策略。跨域的 prefetch 请求在绝大多数浏览器中会被直接忽略，即使服务端正确配置了CORS响应头也无济于事。

如何正确书写才能让 prefetch 生效

最基本的写法就是一行代码：。但要让这行代码真正起作用，还需要满足几个硬性条件：

• 路径必须合法：href 属性必须是绝对路径，或者相对于当前页面的完整URL。像 //cdn.example.com/xxx.js 这种协议相对路径会被视为非法协议，导致请求失败。
• 无需指定类型：通常不需要添加 as 属性。浏览器会根据文件后缀名或HTTP响应的MIME类型自动推断资源类型；画蛇添足地加上，反而可能被某些浏览器忽略。
• 避免与 preload 冲突：切忌对同一个资源同时使用 preload 和 prefetch。例如，对同一个 main.js 同时使用两者，Chrome会发起两次独立的请求，这纯属资源浪费。
• 缓存策略是关键：预取资源的HTTP响应头必须包含强缓存指令，例如 Cache-Control: public, max-age=31536000。否则，当用户真正跳转到目标页面时，缓存可能已经失效，之前的预取工作就白费了。

一个标准的示例： —— 直接放置在HTML文档的 区域即可，无需等待DOM加载完成。

想深入了解前端性能优化？可以看看这份“前端免费学习笔记（深入）”。

为什么在开发者工具里看不到 prefetch 请求

这是一个常见的困惑点：明明在代码中正确书写了 prefetch，但在 Chrome DevTools 的 Network 面板里却找不到对应的请求记录，或者请求状态显示为 Priority: Low，但一直处于 cancelled（已取消）或 pending（挂起）状态。

• 请求根本没发出：可能页面尚未触发 onload 事件（例如有长任务阻塞了主线程），或者用户操作太快，在预取发起前就跳转走了，浏览器便会主动取消该任务。
• 被浏览器策略拦截：Firefox 默认可能关闭了 prefetch 功能（取决于 network.prefetch-next 配置）；Safari 对 prefetch 的支持则比较有限，尤其是对非脚本类资源。
• 资源路径或权限问题：prefetch 请求如果遇到404或CORS错误，通常不会在控制台抛出JS错误，但你可以在 Network 面板里找到这些失败的请求，状态码会是404或 net::ERR_FAILED。
• 正确的验证方法：打开 Network 面板，在筛选器（Filter）中输入 prefetch，同时确保类型筛选勾选了“All”而不仅仅是“XHR”。刷新页面后，观察是否出现了 initiator 为“Other”且 Priority 为“Low”的请求条目。

prefetch 与 preload：那些容易踩坑的混淆点

两者虽然都使用 标签，但语义、触发时机和作用域截然不同。一旦用混，性能优化很可能变成“性能负优化”。

• 错把 preload 当 prefetch 用：例如，在首页为搜索页的 search.js 写 。这会导致该资源在首页解析HTML的早期阶段就以高优先级争夺带宽，反而拖慢首屏加载。而且，这个预加载的资源通常只能被当前页面使用，跳转到搜索页后无法复用。
• 错把 prefetch 当 preload 用：例如，为首屏的横幅大图（hero image）写 。结果就是，图片要等到页面 onload 后才开始慢悠悠下载，用户早就看到一片空白或者低质量的占位图了。
• 服务端渲染（SSR）中的动态注入逻辑错误：在SSR时，根据路由预测用户下一步行为并动态注入 prefetch 链接，但如果预测逻辑有误（比如给所有用户都预取了后台管理页面），就会产生大量无效请求，浪费资源。
• 构建工具插件配置失误：例如，Webpack 的 preload-webpack-plugin 默认只处理 preload，如果错误配置成对所有异步代码块（async chunk）都插入 prefetch 链接，会瞬间造成浏览器缓存的大面积污染。

说到底，区分二者的核心边界在于：当前页面“立刻就要用”的资源，只考虑 preload；当前页面“大概率用不上，但用户下一步很可能需要”的资源，才是 prefetch 的用武之地。 这个判断一旦出错，所有的优化努力都可能适得其反。