前端面试：如何安全使用 fetchpriority 优化 LCP 图片？

题目

页面的最大内容绘制元素通常是一张响应式图片。请设计使用 fetchpriority、loading、preload 和 srcset 的优化方案，并说明实验、回滚和可访问性要求。

场景与约束

桌面与移动端的 LCP 图片不同，页面还加载字体、关键 CSS 和分析脚本。浏览器会自行调度资源，优先级提示只是提示；不能假设所有浏览器都以相同方式执行。

核心考点

考察能否区分发现时机、加载策略和请求优先级。fetchpriority=high 提高资源在浏览器队列中的相对优先级，loading=eager/lazy 影响是否延迟加载，preload 提前声明资源；三者叠加可能造成重复请求或挤占 CSS、字体带宽。

参考解法

先用真实用户数据和性能面板确认 LCP 元素及其请求链，再只给确定的首屏 LCP 图片设置高优先级。使用 srcset 与 sizes 选择合适尺寸，避免同时预加载桌面和移动资源。不要给列表图片批量设置 high，也不要把首屏图片设为 lazy。通过实验比较 LCP、关键 CSS 完成时间、总字节和长任务，逐步扩大流量。

关键细节

响应式图片的候选资源必须与 preload 的 imagesrcset、imagesizes 一致，否则可能预加载一张、最终渲染另一张。检查 Network 面板的 priority、Initiator、缓存命中和请求时序；在低端设备与慢网络上验证。保留删除提示的开关和回滚版本。

常见误区

把 high 当成强制下载；所有图片都 high；用 preload 代替正确的 HTML 图片；只看 Lighthouse 不看真实用户；忽略图片 alt、尺寸占位和跨域缓存；在没有基线时宣称 LCP 一定改善。

评估标准

优秀答案能说明选择 LCP 候选、资源优先级冲突、响应式一致性、实验指标和回滚条件，并承认浏览器实现差异。一般答案只给出一个属性，没有验证请求队列和真实用户结果。

追问

什么时候只用 preload 而不用 fetchpriority？

当资源在 HTML 早期不可发现、且确实需要提前建立请求时可考虑 preload；若浏览器已能及时发现图片，优先级提示通常更小且更易回滚，仍需实验确认。

如果 LCP 变好但字体变慢怎么办？

比较关键 CSS、字体和图片的请求时序与带宽占用，降低非必要图片优先级或移除重复 preload，设置字体加载策略后再复测。

如何保证图片优化不损害可访问性？

保留准确的 alt、明确宽高或比例占位防止布局偏移，确保低带宽与禁用图片时仍有可理解内容，并在真实辅助技术上检查。