rel="preload"仅适用于当前页面明确马上要用的关键资源；核心判断标准是资源是否在HTML解析早期就被CSS/JS依赖但浏览器默认发现太晚，如字体、关键CSS、动态导入JS等。
能提升，但只对“当前页面明确马上要用”的资源有效；用错反而拖慢首屏、浪费带宽。
什么时候该用 rel="preload" 而不是普通 <link> 或 <script>
核心判断标准是：资源是否在 HTML 解析早期就已被 CSS/JS 依赖，但浏览器按默认顺序发现太晚。典型场景包括：
- 字体文件（
font.woff2）被 CSS 中的@font-face引用，但 CSS 文件本身加载完、解析后才触发字体下载 → 首屏文字会 FOIT/FOUT - 关键 CSS（如首屏样式）体积大，且被
<link rel="stylesheet">放在<head>底部 → 渲染阻塞延迟 - 某个 JS 模块会被
DOMContentLoaded后立即import()，但网络发现靠后 → 动态导入卡顿
这些情况用 <link rel="preload" href="xxx" as="font" crossorigin> 可让浏览器在解析 <head> 第一行时就发起请求，不等 CSS/JS 解析完成。
as 和 crossorigin 属性为什么不能省
as 决定浏览器如何调度优先级和复用缓存；crossorigin 影响字体/CORS 资源能否被正确使用。漏掉任一者，预加载可能完全失效或降级为普通 fetch：
立即学习“前端免费学习笔记（深入）”；
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
-
as="font"：告诉浏览器这是字体，启用 high 优先级 + 字体专用缓存策略；若写成as="fetch"或不写，Chrome 会按 low 优先级处理，且无法被@font-face复用 -
crossorigin：字体几乎总是跨域加载，不加该属性会导致预加载成功但 CSS 中@font-face拒绝使用它（CORS 错误），表现为字体不生效、回退到系统字体 -
type="font/woff2"可选但推荐，帮助浏览器跳过不支持格式的请求（如旧版 Safari 不支持 woff2）
验证方式：打开 Chrome DevTools → Network 面板，筛选 Preload 请求，看 Priority 是否为 high，且 Initiator 是 html 而非 css 或 js。
为什么 preload 不能替代 prefetch 或懒加载 JS
三者定位完全不同，混用会破坏预期行为：
-
preload：只服务当前导航，强制 high 优先级，必须配as，资源加载完暂存，需手动触发使用（如onload="this.rel='stylesheet'"） -
prefetch：目标是下一页，Priority=low，空闲时才下载，不保证命中，对首屏无影响也不应滥用（比如全站 prefetch 所有 JS） - JS 懒加载（如
loading="lazy"for<img>或IntersectionObserver）：依赖滚动/视口判断，preload无法替代——它不会等用户滚动，而是立刻加载
常见错误：给懒加载图片同时写 src 和 <link rel="preload" as="image">，导致重复请求；或对非关键 JS（如统计脚本）用 preload，挤占首屏带宽。
预加载 CSS 的正确写法与风险点
预加载 CSS 不等于直接替换 <link rel="stylesheet">，它只负责下载，不自动应用：
- 必须配合
onload回调切换rel：<link rel="preload" href="critical.css" as="style" onload="this.rel='stylesheet'"> - 不能省略
as="style"，否则浏览器无法识别为样式表，不会设 high 优先级 - 若 CSS 内含
@import，预加载只下载主文件，不递归预加载被 import 的资源；构建时建议用 PostCSS 自动内联或拆分 - 避免对 media 查询条件加载的 CSS（如暗色主题）用 preload —— 应改用
<link media="(prefers-color-scheme: dark)">，由浏览器按条件触发
真正容易被忽略的是：预加载资源一旦声明，浏览器就会发起请求，无论后续逻辑是否真用到它。所以它不是“优化开关”，而是“确定性承诺”——没想清楚就加，等于主动制造冗余请求。
