应优先用preload加载当前导航中确定马上要用的关键资源，如字体、首屏css、动态import的js；prefetch仅用于用户行为可预测的后续页面低优先级资源，二者不可混用，错配将拖慢首屏。

什么时候该用 preload 而不是 prefetch

直接判断标准：资源在当前页面导航中是否「确定马上要用」。是，用 preload；否，用 prefetch。

常见错误现象：prefetch 被写进首屏字体或关键 CSS 的 link 标签里，结果浏览器把它当低优先级处理，首屏文本渲染卡顿、FOIT 时间变长；反过来，把用户几乎不会点的后台模块 JS 用 preload，反而抢占 HTTP/2 流和带宽，拖慢真正关键资源。

• preload 请求在 Chrome DevTools Network 面板里显示为 Priority: high，且发起时间极早（常在 HTML 解析前）
• prefetch 显示为 Priority: low，通常在页面加载完成、空闲时才发起
• 对第三方 CDN 上的字体，必须同时用 preload + crossorigin，否则浏览器会忽略预加载并重复请求

preload 的 as 属性为什么不能省略

省略 as 会导致浏览器无法正确判断资源类型，进而错配优先级、缓存策略甚至 MIME 处理逻辑。比如不写 as="font"，WOFF2 字体可能被当成普通二进制文件下载，无法参与字体加载优化流程，FOIT 问题照旧。

Article To Html

文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。

下载

常见取值与对应场景：

• as="style"：用于关键 CSS，确保解析时机与样式表合并逻辑一致
• as="script"：配合 defer 或动态 import() 使用，避免脚本执行阻塞
• as="font"：必须搭配 crossorigin 和 type="font/woff2"，否则无效
• as="image"：适用于首屏 img 或 CSS 背景图，但注意不要和 loading="eager" 冲突

如何验证 preload 是否生效且没浪费

光加了标签不等于起作用。最直接的方式是打开 Chrome DevTools → Network 面板，过滤 Preload 类型请求，看是否出现、是否返回 200、是否被后续资源复用（即同一 URL 在后续 link 或 script 中未重新发起请求）。

• 若看到 Preload 请求后，相同 URL 又发起一次 Stylesheet 或 Script 请求，说明资源未被复用——大概率是 href 路径不一致（大小写、斜杠、查询参数差异）
• 若 preload 资源在页面生命周期内始终没被引用，DevTools 会标记为 “preload was not used” 警告，这是典型的带宽浪费
• 对字体，检查 Application → Fonts 面板，确认预加载字体是否出现在列表中且状态为 “loaded”

用 media 属性做条件预加载容易忽略什么

media 是让 preload 更精准的关键，但它只控制是否发起请求，不控制资源是否被使用。比如写了 media="(min-width: 768px)" 预加载高清图，但 JS 逻辑在所有屏幕尺寸下都尝试加载这张图，小屏设备仍会发请求并丢弃——白白消耗流量。

• 必须确保 media 查询与实际资源使用逻辑严格一致，最好和后续 img[srcset] 或 CSS @media 规则保持同步
• 服务器端渲染（SSR）场景下，media 判断发生在客户端，服务端无法感知，可能导致首屏水合不匹配
• 不要对 as="script" 使用复杂 media，JS 加载逻辑往往跨尺寸通用，条件判断应放在 JS 内部而非预加载层

实际应用中，最易被跳过的细节是：预加载资源的 URL 必须与最终使用它的 URL 完全一致（包括协议、域名、路径、查询参数），哪怕多一个斜杠或大小写不同，浏览器也视为两个资源，无法复用缓存。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！