首屏加载卡在图片上：LCP优化实操

星图导航配图

先定位到底是哪张图拖后腿

LCP 是最大内容元素的绘制时间，通俗说就是首屏那块最大的东西什么时候显示出来。对大多数站点，这块东西是首屏大图或者大标题区块。

定位方法：浏览器开发者工具打开性能面板，录一段加载过程，看 LCP 标记落在哪个元素上。也可以跑一遍 Lighthouse，它会直接告诉你 LCP 元素是哪个、耗时多少、卡在哪个阶段。

卡在四个阶段之一：服务器响应慢、资源加载慢、元素渲染被阻塞、或者图片本身太大解码慢。先把阶段分清，再动手，不然改半天指标不动。

压体积。首屏图从 1MB 压到 200KB，LCP 常常能快一秒以上。转 WebP 或者 AVIF 再压一遍质量，双管齐下最有效。

给图定尺寸。图片实际像素尺寸别超过显示尺寸太多，一张 4000 像素宽的图塞进 300 像素宽的容器，白白多下载十几倍数据。上传前先缩到显示尺寸的两倍以内，兼顾高清屏。

给标签写宽高。不写宽高的图会让布局在加载时抖动，也会让浏览器无法提前预留位置。写上 width 和 height，布局稳定，LCP 和 CLS 一起改善。

把首屏图改成预加载。在 head 里加一条 preload，把首屏图提前拉到高优先级队列，别让它排在几十个请求后面等着。

首屏图绝对不能懒加载。很多人为了省流量，给所有图都加了延迟加载，结果首屏大图也在等滚动事件触发，LCP 自然爆掉。懒加载只给首屏以下的图用。

fetchpriority 别设反。首屏大图设 high，其余图设 low 或者默认。全站都设 high 等于没设，浏览器还是按顺序来。

别用 CSS 背景图当首屏主图。背景图在 CSS 解析完之后才开始下载，比 img 标签晚一步，而且不能被 preload 直接命中。能用 img 就用 img。

图片走 CDN 或者至少开浏览器缓存。给图片设一个长缓存时间，一年过期，文件名带版本号，改图就改文件名。这样回访用户完全不用重新下载。

开 gzip 或者 brotli 对图片没用，图片本身已经压缩过。这两个留着压 HTML、CSS、JS 就够。

如果图片放在服务器本地，注意 nginx 的 sendfile 和缓存头配置。配置文件里给静态资源加 expires 和 cache-control，这一条改动小、收益大。

很多人只盯着图片，其实 LCP 卡在第一个阶段是服务器响应。首页要 2 秒才吐出第一个字节，图再小也没用。判断方法很简单，看性能面板里的 TTFB，超过 0.5 秒就该查服务端。

服务端慢的常见原因：数据库查询没走索引、页面里循环查库、开了太多 PHP 进程把内存挤爆、磁盘 IO 打满。先看慢查询日志，再看负载和内存，最后看 PHP-FPM 的进程数和排队情况。

缓存是最便宜的加速手段。页面级缓存命中时不用查库不用渲染，TTFB 能压到几十毫秒。静态资源交给 nginx 直接返回，别让 PHP 去读文件再吐出来。

办公室测出来 0.8 秒，用户手机上可能是三秒。原因三个：移动网络延迟高、手机 CPU 解码图片慢、屏幕小但下载的图还是桌面尺寸。

做法：用响应式图片，按屏幕宽度给不同尺寸的源，让手机下载小图。srcset 配 sizes 两个属性，浏览器会自己挑。这一步对移动端 LCP 的提升比对桌面端明显得多。

测的时候把网络限速打开，模拟 4G 或者更差的网络，再用手机真机测一遍。数据好看不代表用户用着快，以真机弱网为准。

先测出 LCP 元素和卡住的阶段，再按阶段动手：服务端慢就上缓存和查慢查询，资源慢就压图和加 preload，渲染被阻塞就把阻塞的脚本挪走或者加 defer。

改一项测一项，别一次改五个地方然后不知道是哪个起了作用。每次改完记录一组数据，一个月下来你就知道自己站点最有效的优化动作是哪个。

还有一个容易被忽略的点：大图用 JPG 比用 PNG 解码更快。PNG 解码要做完整的解压运算，同样尺寸的图，手机解 PNG 明显比解 JPG 吃力，解码时间也会算进 LCP。首屏大图优先用 JPG 或者 WebP，别用 PNG。这条在低端安卓机上差别尤其明显。

CDN 预热也值得做。首屏图提前推送到边缘节点，用户请求时不用回源，这一步对跨地域访问的提升很直接。新发文章、新换首图，顺手预热一下，几十秒的事。

最后，把改动记下来。今天动了哪几项、指标从多少到多少，写在一个小本子上。下次换服务器或者改模板，照着清单重做一遍，不用重新摸索一遍，也不会漏掉某一项。

如果时间有限，只做两件事：把首屏图压到 200KB 以内、首屏图绝不懒加载。这两条能覆盖大部分站点的改善空间，剩下的细节可以慢慢补。