cls优化需确保渲染时序与尺寸预期一致：图片/iframe须设内联宽高或aspect-ratio，字体加载需font-display+尺寸控制，动态内容须预留空间，第三方脚本要监控注入节点。
CLS 优化不是加个 width 和 height 就完事的——它本质是控制渲染时序与尺寸预期的一致性，而多数人卡在「以为图片加了宽高就稳了」这一步。
图片/iframe 缺失宽高导致 CLS 突增
浏览器在解析 HTML 时，若 <img> 或 <iframe></iframe> 没有明确的 width 和 height（或 CSS 中未设固定尺寸），会先以 0×0 占位，等资源加载完成再重排，造成下方内容突然下移。
- 必须为所有
<img>提供内联width和height属性（注意：不是仅靠 CSS）；现代做法推荐用aspect-ratio+width: 100%配合height: auto，但需确认目标浏览器支持（Chrome 88+、Firefox 89+） -
<iframe></iframe>同理，不能只靠 CSS 宽高，必须带width和height属性，否则即使设置了aspect-ratio，部分浏览器仍会触发 layout shift - 响应式图片慎用
srcset+sizes却不配width/height：浏览器可能按默认尺寸占位，等srcset解析后才调整，造成两次偏移
字体加载引发的 FOIT/FOUT 偏移
自定义字体加载期间，浏览器用后备字体渲染，等 Web Font 加载完成再重绘，若两种字体行高、字宽差异大，文本块高度变化就会拉扯布局。
- 用
@font-face的font-display: optional或swap，避免阻塞渲染；但swap可能导致 FOUT（内容重绘），需配合size-adjust或font-size-adjust控制字体替换时的尺寸稳定性 - 关键文本容器（如标题、按钮）建议预设
line-height和min-height，防止字体切换时容器高度塌缩或撑开 - 避免在
font-family列表中混用等宽与比例字体（如"Monaco", "Helvetica"），它们的ch和ex单位行为差异大，易导致宽度跳变
动态内容插入没预留空间
广告、评论、推荐模块等 JS 动态注入的内容，若没有提前占位，插入瞬间会把原有内容往下顶，CLS 直接飙升。
- 用
<div style="min-height: 300px"></div>或<div aria-hidden="true"></div>占位，高度尽量接近真实内容均值（可结合服务端预估或客户端缓存历史尺寸） - 避免用
visibility: hidden或opacity: 0替代占位——它们不脱离文档流，但无尺寸，等于没占位 - 使用
content-visibility: auto可提升长列表性能，但它本身不解决 CLS；若开启后子元素首次渲染仍无尺寸约束，偏移照旧
第三方脚本与样式注入不可控
Google Ads、Facebook Pixel、客服 Widget 等常在 DOMContentLoaded 后异步注入 DOM 节点或内联样式，且不提供尺寸声明，是 CLS 黑盒来源。
- 检查第三方脚本是否注入了无宽高的
<div> 或覆盖了全局 <code>body样式（如意外添加margin-top）；可用 Chrome DevTools 的 Layout Shift Regions 面板定位具体节点 - 对已知问题脚本，用
<link rel="preconnect">提前建立连接，但更有效的是用loading="lazy"或延迟加载时机（如用户滚动到视口再初始化） - 禁用
document.write——它强制同步阻塞并重写 DOM，极易引发不可预测的 layout shift；现代第三方 SDK 多已弃用，但老版本仍存在
CLS 是个合成指标，单点修复常无效。最常被忽略的是：**同一元素在不同设备上因响应式断点导致的尺寸不一致，会分别触发多次偏移，但 Lighthouse 默认只报最大单次值**。查问题别只盯着瀑布图顶部那条红杠，得打开 Performance 面板逐帧看 layout shift event 的 target node 和 delta。
