预加载抢带宽的典型现象是Chrome DevTools Network面板中Priority列为High的资源挤占hero.jpg或main.css下载时间线，且同一URL在Initiator列同时显示Parser和img，表明重复请求发生。
预加载抢带宽的典型现象怎么识别
Chrome DevTools Network 面板里，Priority 列显示为 high 的资源如果挤占了 hero.jpg 或 main.css 的下载时间线，基本就是 preload 抢带宽了。更直接的证据是：同一 URL 在 Initiator 列同时出现 Parser（来自 preload）和 img（来自实际 <img src>），说明重复请求已发生。
哪些 preload 会无条件抢占首屏带宽
浏览器对 <link rel="preload"> 是“见令即发”，不等渲染上下文、不看资源是否真被用到。以下写法会立刻触发高优先级请求：
-
<link rel="preload" href="chunk-abc123.js" as="script">—— 即使该 chunk 属于非首屏路由，也会在 HTML 解析阶段就拉下来 -
<link rel="preload" href="video-poster.mp4" as="video">—— 用户还没滚动到视频区域，它已占掉 2MB 带宽 -
<link rel="preload" href="font.woff2" as="font">漏写crossorigin—— 请求发出但字体被丢弃，带宽白耗
as 属性写错导致的隐性带宽浪费
as 值不是可选标签，它直接决定浏览器如何调度连接、复用 TCP、设置缓存策略。写错等于让 preload 失效，还可能触发降级 fetch：
-
as="fetch"用于 JS 文件 → 浏览器按普通 AJAX 请求处理，不进 script 缓存，也不参与解析队列 -
as="text/css"用于 CSS → 被忽略，后续<link rel="stylesheet">仍要重新发起请求 -
as="image"但服务端返回Content-Type: image/jpeg，而标签里写了type="image/webp"→ 匹配失败，资源被丢弃
真正该用 preload 的资源长什么样
只有同时满足这三条，才值得加 preload：
立即学习“前端免费学习笔记（深入）”；
- 路径完全静态：
href="/fonts/inter-latin.woff2"✅，href="/fonts/<code>theme.woff2" ❌（模板语法不被解析） - 当前导航中「立刻要用」：比如内联
<style>里引用了该字体，且文本渲染不能等 - 浏览器默认发现太晚：字体藏在异步加载的 CSS 里，而 CSS 本身又没设
media="print"延迟加载
字体必须配 font-display: swap，否则 preload 只会让 FOIT 更明显；图片 preload 必须配合 media 属性做条件触发，比如只在桌面端预载大图。
