fetchpriority="high"对白屏时间几乎没用，因其仅影响图片网络请求排队顺序，而FCP取决于HTML解析、CSSOM构建和JS执行完成，三者任一阻塞都会使图片优先级失效。
fetchpriority="high" 本身不减少首屏白屏时间，它只在 Chromium 112+ 中尝试让关键图片更快进入网络请求队列——但白屏结束（即 FCP）取决于 HTML 解析、CSS 构建、文本渲染和首屏布局是否就绪。图片再快也救不了没文本、没样式、被 JS 卡住的页面。
为什么fetchpriority="high"对白屏时间几乎没用
首屏白屏时间（Time to First Paint / FCP）卡在三个地方：HTML 解析阻塞、CSS 阻塞渲染、JS 同步执行。浏览器连 <h1> 都没解析出来时，<img> 的优先级再高也无从谈起。
- 白屏结束标志是「首次绘制非空白内容」，通常是文本或内联 SVG，不是图片
-
fetchpriority只影响图片的网络请求排队顺序，不影响 DOM 解析、CSSOM 构建或 JS 执行 - 若首屏没有文本节点（比如全靠 JS 渲染），哪怕
fetchpriority="high"生效，FCP 仍会严重延迟 - 服务端返回 HTML 太慢（TTFB > 500ms）、或 HTML 里嵌了同步
<script>，fetchpriority完全起不到作用
真正能配合fetchpriority="high"缩短白屏的三件事
它只是拼图一角，必须和以下操作协同才可能让首屏“看起来更快”：
-
首屏文本必须写死在 HTML 前 2KB 内：比如
<h1>、<p>直接出现在<body>开头，不包在<div class="container">或 JS 组件里 -
关键 CSS 必须内联：把 header、标题、按钮等首屏样式直接塞进
<style>标签，避免外链 CSS 阻塞渲染 -
所有
<script>加defer：禁止出现<script src="app.js"></script>这种无属性写法；即使放在<head>，也要加defer让它不打断 HTML 解析
fetchpriority="high"生效的前提条件（漏一条就白配）
它不是加了就起效的开关，而是一组硬性约束下的提示信号：
立即学习“前端免费学习笔记（深入）”；
- 必须用在原生
<img>标签上，且src是服务端直出的真实 URL（不能是data-src、空字符串或 JS 后续赋值） - 必须搭配
loading="eager"——loading="lazy"或未声明会覆盖 high 提示，强制降为 Low - 必须显式设置
width和heightHTML 属性（不是 CSS），否则浏览器无法预留空间，导致布局偏移（CLS），间接推迟 LCP 判定 - 验证必须在 Chrome DevTools Network 面板中禁用缓存、前台标签页刷新，并勾选 Priority 列：只看是否显示
Highest或High，其他全是失效
更值得优先做的替代方案
比起纠结 fetchpriority，这几件事对白屏时间的影响大得多：
- 把首屏大图换成内联 SVG 或 base64 占位（
src="data:image/svg+xml,%3Csvg..."），完全绕过 HTTP 请求 - 用
<link rel="preload" as="image" href="/hero.jpg">替代fetchpriority：它能在 HTML 解析早期就发起请求，比fetchpriority更底层、更确定 - 服务端启用 Brotli 压缩 + 设置
Cache-Control: public, max-age=300，降低 TTFB —— 白屏起点就是 HTML 到达浏览器的时间 - 禁用所有非必要第三方脚本（统计、广告、客服），它们常是白屏最大黑盒阻塞源
复杂点在于：你得先确认白屏到底卡在哪——是 HTML 慢？CSS 阻塞？还是 JS 同步执行？fetchpriority="high" 只解决其中最末端的一个子问题：某张图在网络队列里能不能排前面。它不解决“图从哪来”，更不解决“字怎么还不出来”。
