模糊占位图好看，但它会让 LCP 的数字骗人。今年 2 月我们查一个设计工具站，GSC 里 LCP 是 0.9 秒，用户却在群里说"打开要三秒"。原因就是首图用了 20×20 的 base64 模糊图，浏览器把 LCP 记在了这张低清图上。
LCP 记的是"画出来的那一刻"
LCP 的定义是视口内最大内容元素的渲染时间。模糊占位图先渲染，尺寸已经撑满，浏览器就认为 LCP 完成了。真图两秒后替换上去，指标不会重算。
这不是说模糊图不能用，是说它会让监控失效。我们给这个站加了自建埋点，记录"首图高清版加载完成"的时间，P75 是 2.6 秒，和用户感受对得上。
更麻烦的是体验本身
模糊图从小图放大，在移动端看起来就是一团色块，用户会以为页面坏了。这个站移动端跳出率 58%，比同类站高出一截。
改法两条：首屏图不用 LQIP，直接用最终尺寸的 WebP 加 fetchpriority="high"；折叠线以下的图才用模糊占位，那时候用户还没看到，不影响首屏感受。
如果一定要用占位
三个要求：占位图要清楚到能看出内容轮廓，我们一般用 32×32 起步；真图加载完要有淡入，避免生硬跳变；埋点单独记"高清图完成时间"，别只信 LCP。
一个更干净的替代方案：纯色或者渐变占位，配合正确的宽高比。这种占位不会干扰 LCP 记录，视觉上也干净。我们现在默认推荐这个，模糊图只留给图册类页面。
怎么跟设计团队谈
设计师喜欢模糊占位，因为它让加载过程显得精致。我们的说法是：可以保留占位的美感，但首图除外。首图是用户对速度的第一印象，让他先看到一团模糊，再等两秒变清晰，感受比直接等两秒更差。
这个站最后是折中方案：首图不做 LQIP，改成低饱和度的渐变占位；图册和案例详情页保留模糊过渡。改完设计没意见，数据也回来了。
一个判断标准
如果你发现 LCP 数据很好、用户却说慢，先查首屏图是不是用了 LQIP 或者骨架图。这是我们在 5 个站上验证过的高频原因，排查只要看 Elements 里第一张图的 src 是不是 data URI。
顺带说一句：这个站改完并没有让 LCP 变差，反而从"假 0.9 秒"变成真实的 1.6 秒。指标诚实了，后面的优化才有意义。团队一开始不愿意改，因为数字变丑了，我跟他们说：监控的作用是发现问题，不是让报表好看。
元析智能
为软件公司做 SEO 和 GEO 优化