CLS 高，最容易被误判成一句"图片没设尺寸"。可 CLS 并不是把整页所有抖动加起来求和，它取的是一连串连续位移里累计得分最高的那一段。这个口径决定了诊断顺序：先找那一段最重的位移，再回头找是什么把它推下来的。web.dev 的 CLS 指标说明把计算方式写得很直白，可以直接拿来做判断依据。
CLS 到底在数什么
两个条件同时满足才算一次位移：视口里已经可见的元素，在前后两帧之间起始位置变了。新插入的元素、自己变大小的元素都不算——只要它们没有把别的元素挤走。得分等于"影响比例"乘以"距离比例"：前者是不稳定元素在两帧里占视口面积的比例，后者是最远位移距离除以视口最大边。一个占半屏的大块往下挪一点点，得分可能比一条细线挪很远还低。
连续性也有讲究：相邻两次位移间隔不到 1 秒就算同一段，一段最长不超过 5 秒，取其中累计最高的一段。所以"文章往下滚之后底部图片没预留位置"这种加载后才出现的位移，实验室跑分通常量不到，却在真实用户那里照样计入。
四类成因，以及各自的判断线索
成因可以归成四类，web.dev 的 CLS 指标说明在开头就点出了来源：异步加载的资源、在既有内容之前被插入的 DOM 元素、尺寸未知的图片或视频、渲染尺寸与替代字体对不上的字体，以及会自己改变大小的第三方广告与小窗体。落到 WordPress 页面上：
- 没有尺寸的图片：看源代码里
<img>有没有width与height属性。 - 没有尺寸的嵌入与广告位：客服窗体、视频播放器、地图这类 iframe，容器高度是不是 0 或者压根没写。
- 动态插入的内容：横幅、公告、推荐位插进正文流里，检查它出现时把下方元素推走了多少。
- Web 字体替换：正文先用什么字体渲染、最终换成什么字体，两个字体行高和字宽差多少。
读这类诊断报告有个容易忽略的地方：被列出来的往往是被移动的元素，肇事的那一个通常在它上方——一个新块插进来，往下被推的是它下面的正文，报告里显示的却是正文那一行。看报告时把视线往上移一层，才能找到真正该改的地方。
处理顺序：从预留位置开始，最后才动动画
顺序错了会白做工。合理的次序是：
- 先给所有会晚到的内容预留位置：图片写
width与height，或者用 CSS 的 aspect-ratio 预留同样的大小；iframe 写死宽高；广告位用最小高度占住。 - 再处理字体：让字体更早到达，或者让替代字体的度量接近它，减少替换时的行高变化。
- 然后把迟到的第三方内容往后放，别插在正文流中间。
- 最后才把会动的地方从改
height、top这类属性换成改transform——web.dev 在同一份 CLS 说明里指出，用transform缩放和位移可以实现动画而不触发布局位移，改height与width则会。 - 全程留一个降级方案：内容迟到时先显示占位或加载提示，别让用户对着一块空白猜。
页面级缓存、数据库与前端文件的整体处理思路，站内旧文缓存、数据库与前端文件的按需优化已经讲过，这里不重复；判断缓存与服务器分工的思路见加速先选插件还是调服务器。
有位移本来就不计入
用户点击、点按、按键之后 500 毫秒内发生的位移，会被标记为"近期有输入"而排除在计算之外；换句话说，用户刚点了展开菜单、把内容顶下去，这是预期内的。反过来，滚动、拖拽、缩放这类连续手势不算"输入"，在这类操作过程中发生的位移仍然按意外位移计。这一点决定了排查方向：先看没人操作时页面会不会自己动，再看滚动过程中会不会动。
什么时候这套排查不划算
三种情况可以先停手。一是页面的 CLS 本来就在 0.1 以内、且短板明显在加载或交互上，先去处理权重更大的那项。二是模板是单页应用或强交互型后台，正文由脚本渲染，位移来源集中在框架自身的重排，WordPress 层面的改法能起的作用有限。三是一个 URL 的真实数据本身就没达标样本、只有实验室数据可看，此时按实验室那份名单修，修完也无法确认改善是否传到真实用户。
另外要记住 web.dev 的 Web Vitals 说明里那条口径：CLS 在 0.1 或更低算好，按第 75 百分位衡量，移动与桌面分开。这是建议性的体验目标，官方没有公布任何与排名位置对应的换算关系，不要拿它当承诺。
怎么确认位移真的少了
验证分两层。先在实验室里录一次完整的加载过程，看位移列表里剩下的条目是不是从十几条降到个位数，重点看每一段的累计得分有没有真的下降，而不是元素数量减少。然后在真实数据那一侧等一个完整统计周期再看 URL 分组的状态，并确认移动与桌面两端的变化方向一致。如果实验室那份干净了、真实数据没动，通常说明问题出在加载后才出现的那些内容上，回到第二段的四类成因重查一遍。
