CLS 总是修不好?因为你只盯着分数，从没拆开看过它

从开场来看。一个你大概率经历过的场景

打开 Lighthouse，CLS 超标了。于是你做了所有人都会做的事：给 加上 width/height刷新——再调调字体——折腾一下午，还是没有降到及格线。

不是你不努力。而是方向错了：你一直盯着那个总分，从没把它拆开来看。

CLS 不是随便打出来的。它是若干次具体跳动累加而成，每一次跳动都有一个具体的元凶元素。如果不去揪出这些元凶，而是“全局加点尺寸碰运气”，当然经常修不对。老实说，

下面这篇文章把 CLS 从“一个让人头大的分数”彻底拆解：

• 分数到底怎么算出来的？
• 怎么揪出每一次跳动的元凶？
• 为什么你以为已经修好了却没有生效？
• 怎么用数字证明真的修好了？

读完后你会发现修 CLS 已经不再是玄学。

一、先拆开：CLS 分数到底怎么算的

再看单次跳动，波及多大 × 挪多远

页面每发生一次跳动。浏览器会算一个“偏移分数”：

单次偏移分数 = 影响比例 × 距离比例

距离比例好理解：所有跳动元素里挪得最远的那个，移动距离 ÷ 屏幕最大边。比如挪 100 px，屏幕高 500 px → 0.2。

影响比例关键点在于它不是“动的元素本身有多大”，而是“元素跳动前 + 跳动后两个位置合起来的区域占屏幕多少”。

想象手电筒光斑从屏幕顶端扫到底端——光斑本身不大，但它扫过的整条方法都亮过、都晃过眼。元素移动也一样：从 A 到 B，中间那片区域所有使用者都看到东西在闪。所以用“起点+终点并集”来衡量真实波及范围，比单纯看元素大小更诚实。

从多次跳动来看，取最惨的一波。而不是全部相加

C容易让人误以为把页面“一辈子”的跳动全加起来。事实并非如此。

The real algorithm uses a 会话窗口 。defined by three rules:

1. 两次跳动间隔< 1 秒,算同一波。
2. 一波最长 < 5 秒,到点强制结束并开启新一波。
3. {CLS} = 所有波里分数最高那一波的总分。

注意第三条——取最大的一波，而不是全部相加。

说到例外，使用者主动操作产生的布局变化不计入 CLS

If a user clicks a button or types text and page shifts **within 500 ms**。that shift is ignored because it’s considered an expected response . CLS 惩罚的是 “使用者没招惹它、它自己乱动”。说起来，

二、为什么总修不对：你丢了最关键的 sources

• You only looked at total score.
• You never inspected sources。forensic evidence each layout‑shift event provides.

The browser emits a {layout-shift} event that contains a sources a list of “crime scene photos”. Each source includes:

• {node}: 哪个节点导致了这次位移。
• {previousRect}/{currentRect}: 位移前后的坐标和尺寸。
• {previousAttrs}: 跳动前节点拥有的属性，比如是否已有 .

This is “根因证据”。业界已归纳出几类常见根因，并对应到 sources -里的铁证：

If your dominant culprit is “上方广告位突然插入”，给所有图片硬塞尺寸根本无效——真正的问题在于广告位缺少预留空间。