HTML怎样预加载文档所需资源_HTML预加载文档所需资源提示【提示】-html教程-PHP中文网

link rel="preload" 是唯一能让浏览器提前下载关键资源而不执行、不阻塞的声明方式，需指定 as 属性，仅用于首屏立即需要的资源（如字体、主JS、首屏图片），字体必须加 crossorigin，避免滥用导致性能下降。

html怎样预加载文档所需资源_html预加载文档所需资源提示【提示】

怎么用 `link rel="preload"` 提前加载关键资源

浏览器默认按 HTML 解析顺序加载资源，CSS、JS、字体这些关键依赖经常被卡在后面，造成渲染延迟。link rel="preload" 是唯一能让浏览器「提前知道」并主动拉取资源的声明方式——它不执行、不阻塞，只下载。

实操建议：

只对当前页面**立即需要**的资源用 preload，比如首屏大图的对应的 src、内联 CSS 里引用的自定义字体、或紧跟着的 <script type="module"></script> 所依赖的主入口 JS
必须指定 as 属性，否则浏览器无法预判资源类型，可能重复下载或错误复用缓存（例如漏写 as="script"，JS 就不会进 script cache）
避免对 stylesheet 用 preload：它会触发二次 CSS 解析，反而拖慢渲染；改用 rel="preload" as="style" onload="this.onload=null;this.rel='stylesheet'" 手动接管，或直接用 rel="stylesheet" + media="print" 技巧

<link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2" crossorigin><link rel="preload" href="/js/app.js" as="script">

`preload` 和 `prefetch` 到底该选哪个

preload 是「现在就要用」，prefetch 是「以后可能用」。混淆两者会导致资源浪费或加载时机错乱。

常见错误现象：

把路由懒加载的 JS 用 preload —— 页面一打开就下所有路由代码，白占带宽
把首屏字体用 prefetch —— 字体加载滞后，触发 FOUT/FOIT，文字闪动
在 HTTP/2 推送已启用时还加 preload —— 可能和推送冲突，触发重复请求（Chrome DevTools 的 Network 面板里能看到 preload 请求状态为 pending 或 canceled）

判断依据很简单：打开 Chrome DevTools → Network → 刷新页面 → 看 Initiator 列。如果某资源是被 HTML parser 直接触发（显示为 Parser），且时间戳落在 DOMContentLoaded 前 100ms 内，就适合 preload；如果是被某个 JS 动态 import() 触发，就该用 prefetch。

字体预加载为什么总失败？`crossorigin` 是关键

字体文件受 CORS 限制，即使同域，现代浏览器也要求显式声明 crossorigin，否则 preload 会静默失败（Network 面板里看不到请求，控制台也无报错）。

HTML Text Extract

从HTML页面（URL、文件或标准输入）中提取主体内容文本，去除导航、页脚、广告和模板文本。可直接传递给readability_check或其他文本工具。

下载

实操要点：

所有字体 preload 必须带 crossorigin 属性，哪怕服务端没配 CORS header —— 浏览器会按匿名模式发起请求，只要返回 200 就能用
type 属性强烈建议加上，比如 type="font/woff2"，避免 MIME 类型不匹配导致字体被丢弃（尤其在 Firefox 中更敏感）
不要 preload 多个格式：只选你真正支持的格式（如只支持 WOFF2 的站点，就别同时 preload WOFF 和 TTF）

<!-- ✅ 正确 -->
<link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2" crossorigin><p><!-- ❌ 错误：缺 crossorigin，字体不会加载 -->
<link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2"></p>

HTTP Header 里也能写 preload，但有兼容陷阱

通过 Link 响应头发送 preload 指令，能绕过 HTML 解析延迟，在 DNS 查询阶段就启动下载。但不是所有环境都可靠。

容易踩的坑：

Nginx 默认不支持 Link 头多值，写成 add_header Link "; rel=preload; as=style"; 会覆盖前面的头；要用 add_header Link "; rel=preload; as=style" always; 并确保版本 ≥ 1.13.5
Cloudflare 免费版会 strip 掉 Link 头，除非升级到 Pro 或 Enterprise
Service Worker 拦截响应后，手动设置 response.headers.append('Link', '...') 无效 —— Link 头必须由原始服务器发出，SW 无法注入

优先级上，HTML 中的比响应头更可控，调试也更直观。除非你有边缘计算能力且确定链路干净，否则别急着切 Header 方式。

预加载不是越多越好，每个 preload 都在和首屏其他请求抢 TCP 连接、带宽和 HTTP/2 流优先级。最常被忽略的是：删掉那些「以为有用」但实际没被用到的 preload —— 它们只会拖慢真实关键路径。