浏览器流式解析html时自动为资源分配优先级（如highest、high等），但默认策略不合理：首屏关键图常被标为low，而阻塞渲染的css却获high；fetchpriority属性（high/low/auto）可显式覆盖，默认auto，chrome101+支持，但safari仍不支持。
浏览器怎么给资源打优先级
浏览器不是等 HTML 全部下载完才开始干活的，它一边流式解析 HTML，一边提前发现 <link>、<script></script>、<img> 这类标签，然后按内置规则给每个资源分配一个优先级：比如 Highest、High、Medium、Low、Lowest。这个优先级直接决定它在网络队列里的排队位置。
关键点在于：这个分配是自动的，但**不总是合理**。比如首屏大图 <img src="hero.jpg"> 默认被标为 Low，只因为它被归类为“图片”；而一个藏在页面底部的 CSS 文件，只要写在 里，就会拿到 High —— 尽管它对首屏渲染毫无贡献。
fetchpriority 怎么改默认优先级
fetchpriority 是 Chrome 101+（2022 年起）支持的原生属性，用来显式覆盖浏览器默认判断。它只接受三个值：high、low、auto（默认）。
常见用法：
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 首屏关键图加
fetchpriority="high"，强制提升到Highest级别 - 懒加载图或非视口内资源加
fetchpriority="low"，避免和关键请求争带宽 - 不要滥用
high：如果页面有多个fetchpriority="high"，浏览器会降级处理，实际可能变成High而非Highest - 注意兼容性：Safari 目前（2026 年）仍不支持该属性，Firefox 仅部分支持；不能依赖它做功能兜底
为什么 preload 比 fetchpriority 更可靠
<link rel="preload"> 是更底层的指令，它绕过 HTML 解析顺序，让浏览器在遇到该标签前就发起请求。而 fetchpriority 只是调整已有请求的排队顺序。
典型组合用法：
- 对关键字体或首屏 CSS，用
<link rel="preload" as="style" href="critical.css" fetchpriority="high"> -
preload确保提前发请求，fetchpriority="high"确保它不被其他高优请求挤掉 - 单独用
fetchpriority对已阻塞的资源无效（比如已经卡在队列末尾的图片），必须配合preload或提前出现在 HTML 中 -
preload本身没有浏览器兼容性问题，但需注意as值必须准确，否则可能被忽略或误判类型
开发者工具里怎么看真实优先级
Chrome / Edge / Firefox 的 Network 面板中，右键点击任意请求列表的表头，勾选 Priority 列，就能看到每个资源当前的实际优先级标识（如 Highest、Low）。
容易忽略的细节：
- 同一个资源在不同加载阶段可能显示不同优先级（例如预解析阶段标
Medium，后续因fetchpriority调整为Highest） - 某些资源（如跨域字体、第三方脚本）受 CORS 或 referrer policy 影响，可能被浏览器悄悄降级
-
Priority列只反映网络层调度，不等于渲染影响——比如一个Highest图片如果没设置width/height，仍可能引发回流，拖慢渲染
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
