修复过慢的 LCP 图片

最大内容绘制（LCP）衡量的是最大可见元素完成渲染的时刻。多数页面上这个元素就是一张图——首屏横幅、商品照片、文章头图——也就是说，LCP 通常是某一个文件的问题。

第一步：确认到底是哪个元素

不要猜。Chrome DevTools 的 Performance 面板和 Lighthouse 都会明确指出 LCP 元素。来自 Chrome UX Report 的真实用户数据能告诉你线上体验，而它可能与你在办公室 WiFi、高性能笔记本上的体验大不相同。

第二步：停止拖慢它

以下是最常见的"自找的"延迟：

• 给首屏主图加懒加载。 原生懒加载会把请求推迟到布局确认图片接近视口时。对于首屏可见的图，这纯粹是延迟。把不用滚动就能看到的图片上的 loading="lazy" 去掉——仅这一处改动常常能省下一秒。
• 通过 JavaScript 加载它。 由脚本插入的图片，在脚本运行之前无法被浏览器的预加载扫描器发现。把首屏图写进 HTML。
• 用 CSS 背景图。 同样的问题：浏览器必须先下载并解析 CSS 才知道有这张图。首屏请用真正的 img 元素。
• 客户端水合的阻塞。 如果首屏图要等框架挂载后才出现，LCP 就得等 JavaScript。

第三步：提升它的优先级

浏览器会猜测优先级，而且在早期经常猜错：

• 给首屏图片元素加 fetchpriority="high"。一个属性的改动，效果可测量。
• 可以在 head 里为该图片 URL 加一条 preload——当图片被发现得太晚时很有用。务必确保 preload 与实际请求使用相同的 URL 和相同的响应式属性，否则会下载两次。
• 如果框架默认懒加载，就显式写上 loading="eager"。

第四步：把文件变小

优先级只能让大文件更早开始传，并不能让它变小。

• 提供正确的尺寸。 显示宽度 1200 像素的首屏图，不该是 3000 像素的文件。用响应式尺寸让手机拿到手机尺寸的图。
• 使用现代格式。 同等观感下，AVIF 或 WebP 通常比 JPEG 节省 25–50%。
• 通栏首屏图目标控制在 200 KB 以内，移动端更少。
• 压缩到目标体积，而不是靠肉眼调质量，发布前在 100% 下对比一次。

第五步：把它送得更快

• 用 CDN，让文件从就近节点发出。
• 配合内容哈希文件名设置长缓存。
• 避免图片 URL 上的重定向链——每一跳都是一次往返。
• 如果图片托管在其他域名，提前 preconnect。

顺序很重要：先去掉延迟（免费），再提优先级（几乎免费），然后压小文件（略费工），最后优化分发。多数网站在前两步就能找到自己的 LCP 问题。