CLS 不全是字体的锅：iframe、嵌入组件和动态广告位这三个坑

先对齐口径：0.1 是及格线，看的是真实用户

CLS 是 Core Web Vitals 里唯一一个没有单位的指标，算法上是每次意外位移的「影响范围 × 移动距离」累加。谷歌的分档是 0.1 以内良好，0.1 到 0.25 需要改进，超过 0.25 差，按真实用户加载的第 75 百分位判定。

这句话的重点是「真实用户」。实验室跑出来的分数常常偏低，因为测试环境里广告网络不会慢、第三方脚本不会超时。你在 Lighthouse 里看到的 0.02，到了用户手机上可能是 0.3。

图片来源：网络，版权归原作者所有，侵权请联系删除

坑一：iframe 和嵌入组件不知道自己多高

目录站为了好看，条目详情页里常嵌对方站点的预览、地图、视频或者社交卡片。这类组件在加载完成之前，平台并不知道它最终多高，也不会替你留位置。等它一到位，下面所有内容整体下移。

解法就是显式告诉浏览器它的比例：

.embed { aspect-ratio: 16 / 9; width: 100%; height: auto; }

不支持 aspect-ratio 的老浏览器，用 padding-top 百分比的老办法兜一层。视频类统一 16:9，地图和社交卡片按平台给的容器来，别自己拍脑袋定高度。

还有一个目录站专属的场景：条目卡片里的缩略图。如果从第三方抓来的图没有固定尺寸，且你又做了等比缩放，那么每张图加载完都会顶一下。缩略图容器必须写死宽高，图片用 object-fit 填进去，不要让容器被图片撑开。

坑二：广告位等到竞价结束才出现

广告是网页布局位移的最大单一来源之一，这句话在官方文档里写了好几年。广告联盟普遍支持动态尺寸——尺寸大点击率高、参与竞价的广告主多，收益更好，代价就是页面被往下挤。

目录站通常把广告放在列表中间或者条目卡片之间，一旦挤，挤的是用户正在看的那一屏。做法是给广告槽预留最大可能尺寸：

.ad-slot { min-height: 250px; width: 100%; }

响应式广告用媒体查询给不同断点配不同预留高度。广告比你预留的小怎么办？宁可留白，也不要让内容跳。留白是丑，跳动是用户点错条目，后者会直接影响出站点击。

如果联盟给的是可变高度且你压根控制不了，那就把这个广告位移到正文之后、用户不太可能正在阅读的位置。这是妥协，但比留着跳动强。

坑三：加载完才插进来的那些横条

cookie 提示、订阅弹条、促销横幅、客服挂件。它们的共同点是初始 HTML 里没有，等 JS 跑起来才往 DOM 里塞，而且通常塞在顶部。

三条出路，按优先级排：

1. 预留位置：JS 知道横条多高，就在 HTML 里先放一个等高的占位块，真实内容到位后原地替换。
2. 改成浮层：用 position: fixed 覆盖在上面，不进入文档流，就不会推动任何东西。cookie 条本来就该这么做。
3. 等用户操作再出现：这条最省事，因为交互后 500 毫秒内的位移不计入 CLS。用户点「加载更多」展开的内容是被豁免的，定时弹出或滚动触发的不算。

顺带说两个容易漏的

• 动画属性：用 top、left、width、margin 做的动画每帧都触发重排，加载期间就会计入 CLS。换成 transform 和 opacity，这两个不参与布局计算。
• 水合不一致：服务端渲染出来的 HTML 和客户端渲染结果对不上，客户端重新渲染一遍，页面整体挪位。SPA 架构的目录站尤其要盯这个。

怎么找到到底是哪个元素在动

DevTools 的 Performance 面板里勾上 Experience，能直接看到 Layout Shift 记录和具体元素。线上环境可以挂一个 PerformanceObserver 监听 layout-shift 条目，把 shift 值最大的元素信息上报到自己的统计里——实验室复现不出来的偏移，只能靠真实用户上报抓。

改完别急着下结论。Search Console 的核心网页指标报告是 28 天滚动窗口，今天的改动要一个月后才完整反映出来。中间那段时间用实验室工具做即时信号就够了。