HTML页面构建中的资源预加载技术探讨-html教程-PHP中文网

preload用于当前页面“马上就要用”的关键资源，如首屏图片、核心CSS、字体；prefetch用于未来页面可能用到的资源，需等onload后低优先级加载，且依赖缓存与同源等条件。

html页面构建中的资源预加载技术探讨

preload 和 prefetch 不是可互换的性能“开关”，用错一个，首屏就可能变卡、带宽就被白占。

判断依据就一条：这个资源在当前页面导航中是否「马上就要用」？是 → 用 preload；否 → 用 prefetch 或不用。

preload 在 HTML 解析早期就触发，浏览器以 High/Highest 优先级抢带宽，适合首屏 Hero 图、关键字体、核心 CSS、即将由 import() 动态加载的 JS chunk
prefetch 要等 window.onload 后才发起，且优先级为 Low，常被浏览器跳过（比如用户开了省流模式、内存紧张、网络是 2G）
把本该 prefetch 的商品详情页 JS 写成 preload，会导致首页加载时多发一个高优请求，挤占 CSS/JS 解析带宽，LCP 反而延迟
Chrome DevTools Network 面板里看 Priority 列：若写的是 preload 却显示 low，大概率是漏了 as 属性或路径非法

只写是无效的——浏览器既不知道怎么设请求头，也无法复用到后续 @font-face 加载中。

as="font" 是硬性要求，不写会被降级为普通 fetch，字体无法复用；as="script" 和 as="style" 同理
WOFF2 字体必须加 crossorigin，哪怕同源。Chrome 会直接拒绝应用，且控制台不报错，只静默失败
仅 preload 不够，CSS 中 @font-face 还得配 font-display: swap，否则文本仍会 FOIT（空白等待），预加载白做
避免重复请求：不要在 @font-face 的 src 里写同一地址，又在外面 preload 一次，Safari 尤其容易双下

prefetch 看似简单，但实际生效依赖一连串脆弱条件，写对了也不代表浏览器真会去下。

使用经过文档化的设计技能，从真实的品牌或项目背景中生成HTML原生原型、幻灯片、动态演示、可视化图表和评审流程。

下载

href 必须是合法 URL：不能是协议相对路径（如 //cdn.example.com/a.js），会被当成非法协议直接忽略
必须同源：跨域 prefetch 在 Chrome/Firefox 中基本被无视，即使服务端开了 CORS 也没用
强缓存是前提：响应头必须含 Cache-Control: public, max-age=31536000，否则下次跳转时缓存失效，prefetch 白做
不能和 preload 混用同一资源：比如同时 preload 和 prefetch main.js，Chrome 会发两次请求
DevTools 里找不到请求？先确认页面是否已触发 onload；再检查 Filter 是否选了 All（不是仅 XHR）；最后看状态是不是 cancelled（用户快速跳走）或 net::ERR_FAILED（404 或 CORS）

服务端无法预知的运行时资源（比如根据 UA 加载不同分辨率图片、AB 实验脚本），得靠 JS 主动插入 preload link。

必须用 document.createElement('link') 创建，rel="preload"、as、href 全部设全，然后 document.head.appendChild(link)
越早执行越好，理想位置是 DOMContentLoaded 前；晚于这个时机，可能赶不上关键渲染节点
插入后浏览器立即发起请求，但不会自动执行（script 不运行，font 不生效），后续需手动处理（比如 link.onload 后插入 script 标签）
注意查重：插入前先遍历 document.head.querySelectorAll('link[rel="preload"][href]')，避免反复创建相同 href 的 link 导致内存泄漏