累积布局偏移（CLS）衡量的是页面打开期间，可见内容发生了多少意外移动；在访问的第75百分位上，0.1或以下为良好（web.dev，2023年4月）。高于0.25则为较差。在手机上，常见原因是没有尺寸的图片、没有预留空间的广告和嵌入内容、从顶部插入的横幅和Cookie通知、延迟加载的网页字体，以及会移动布局的动画。请在DevTools中找到发生偏移的元素，然后在它加载前预留其空间。
什么是累积布局偏移
CLS是页面生命周期中最大的一次布局偏移集中，而不是所有偏移的总和。每次偏移的评分是影响比例乘以移动距离比例。影响比例是发生移动的元素所覆盖的视口面积占比；移动距离比例是元素移动的最大距离除以视口的最长边。相隔不到一秒的偏移会被归入一个最长5秒的会话窗口，CLS即为得分最高的那个窗口的值（web.dev）。在用户输入后500毫秒内开始的偏移会被排除在外（web.dev，Optimize CLS，2025年2月）。
| 评级 | CLS（p75） |
|---|---|
| 良好 | 0.1或以下 |
| 需要改进 | 高于0.1，最高到0.25 |
| 较差 | 高于0.25 |
这些是Google规定的“良好分数”阈值，web.dev建议分别检查移动端和桌面端的第75百分位。
为什么CLS在手机上更难控制
同样的移动在小屏幕上得分更高，因为两个比例都是相对于视口计算的，而手机的最长边更短。以上面的公式为例：假设在一个390 × 844 px、内容铺满的视口中，顶部出现了一个80 px高的Cookie横幅，并把所有内容向下推。几乎整个视口面积都受到影响，因此影响比例约为1.0，移动距离比例为80 / 844 = 0.095。得分约为0.095，距离0.1的上限只差一个横幅。这只是一个说明性的例子，它假设内容铺满了视口。
原因与桌面端相同，只是在更小的面积上评分。web.dev指出，广告尺寸在不同设备类型上可能不同，因此为桌面端尺寸预留的空间，在手机上可能是错误的。
另外，CLS并非在所有浏览器中都能测量。web-vitals库将onCLS()列为仅支持Chromium，而它的其他函数在Firefox和Safari中也能使用（web-vitals README）。web-features 3.44.0（2026年10月）也显示布局不稳定性API仅在Chrome和Edge中可用。因此，用该库在现场收集的CLS只覆盖Chromium浏览器；而在iPhone上的Safari中访问时，通过它不会报告任何CLS。
手机上会偏移的元素及修复方法
每个原因都有一种修复方法，即在内容到达之前预留空间。以下来自web.dev的CLS优化指南（2025年2月）：
| 原因 | 修复方法 |
|---|---|
| 没有尺寸的图片和视频 | width和height属性，或CSS的aspect-ratio |
| 广告、嵌入内容和iframe | 用min-height或aspect-ratio预留空间；当没有广告返回时保留占位符 |
| 插入页面的横幅和Cookie通知 | 用占位符预留空间，或将内容覆盖在上方，使其不推动页面移动 |
| 延迟加载的网页字体 | font-display: optional、相近的回退字体、尺寸匹配的回退指标 |
| 动画 | 对transform做动画，而不是top、left或box-shadow |
图片和视频
为每张图片设置固有尺寸，这样浏览器就能在文件到达前预留出方框：
<img src="puppy.jpg" width="640" height="360" alt="Puppy with balloons">img {
height: auto;
width: 100%;
}对于响应式图片，web.dev建议在所有srcset候选项中保持相同的宽高比；对于<picture>，则应在每个<source>和<img>上设置width和height。新的图片格式只会改变文件大小，因此无法解决这个问题；<picture>的写法见WebP vs AVIF。aspect-ratio自2024年3月起已是广泛可用的Baseline功能（web-features 3.44.0）。
广告、嵌入内容和横幅
用你预期的最小尺寸为广告位预留空间；如果手机上的尺寸不同，则使用媒体查询：
.ad-slot { min-height: 250px; }
@media (min-width: 768px) {
.ad-slot { min-height: 90px; }
}这两个高度只是示例，请使用你自己的广告尺寸。web.dev还给出三条建议：把预期的最小尺寸作为最低值；当没有广告返回时显示占位符，而不是收缩空间；把延迟加载的内容放在视口的较低位置，因为在顶部附近插入的内容会造成更大的偏移。对于Cookie通知，应将其做成覆盖层，或从首次绘制起就预留其高度，而不是等脚本决定显示时再把页面向下推。
网页字体
根据web.dev，不可见文字闪烁（FOIT）和无样式文字闪烁（FOUT）都可能造成偏移，因为不可见的文字仍会用回退字体进行布局。web.dev建议使用font-display: optional和相近的回退字体、尺寸匹配的回退指标，并预加载关键字体。相关的值、预加载和回退代码见font-display swap指南。
动画与后退按钮
用transform做动画，因为它不会触发布局。web.dev指出，合成的translate动画不计入CLS。也可以让页面符合前进/后退缓存的条件，因为恢复的页面会以用户离开时的样子显示，不会出现重复的加载偏移。但这对首次加载没有帮助。
如何找到布局偏移
用实验室工具找到元素，再用现场数据确认真实用户是否遇到了它。web.dev列出了以下途径：
- PageSpeed Insights：将现场CLS（来自Chrome用户体验报告）与Lighthouse的实验室CLS进行比较。差距很大通常说明加载后仍有偏移，而实验室运行是看不到这些的。
- Lighthouse：其审核会列出发生偏移的元素及其贡献，但通常只显示受影响的元素，而不是根本原因。
- DevTools的Performance面板：录制一段跟踪，并打开Layout shifts轨道。紫色条表示偏移集群，更大的菱形表示更大的偏移；摘要中会显示开始时间、得分和发生偏移的元素。Layout shift culprits洞察会列出CLS总值及可能的原因（web.dev）。
要看到真实访客中是哪个元素发生了偏移，可以加入web-vitals的归因版本，它会报告最大偏移的目标、时间和数值：
import {onCLS} from 'web-vitals/attribution';
onCLS(({value, rating, attribution}) => {
console.log(rating, value, {
target: attribution.largestShiftTarget,
time: attribution.largestShiftTime,
score: attribution.largestShiftValue,
});
});根据web.dev，iframe内的偏移无法通过Web API测量，但会出现在Chrome用户体验报告中。关于如何运行Lighthouse和其他工具，见Lighthouse移动端审核指南和移动页面速度测试指南。
在手机尺寸下检查布局
桌面端与手机端不同的布局，在手机宽度下最容易发现。Mobile View Extension会以手机的用户代理、屏幕尺寸和像素比重新加载标签页，因此你可以看到页面的移动版本，并观察加载过程中哪些内容发生了移动。它不测量CLS或任何速度指标，而且运行在你的桌面网络上，因此在慢速手机上会使页面偏移的横幅或广告，在这里可能加载得太快而察觉不到。请用上述工具进行确认。关于页面在手机上显示不同的其他原因，见网站在手机上为什么显示不同。
常见问题
CLS的良好分数是多少？
良好的CLS分数是0.1或以下，高于0.25则较差，按页面加载的第75百分位测量（web.dev，2023年4月）。0.1到0.25之间的范围需要改进。
手机上造成布局偏移的原因是什么？
原因包括：没有尺寸的图片和视频；没有预留空间的广告、嵌入内容和iframe；插入的横幅和Cookie通知；渲染比回退字体更大或更小的网页字体；以及改变布局属性的动画。同样的移动在手机上得分更高，因为比例是相对于更小的视口计算的。
怎样找到造成CLS的原因？
在DevTools的Performance面板中录制一段跟踪，打开Layout shifts轨道，然后在摘要中查看发生偏移的元素。对于真实访客，可使用web-vitals的归因版本报告largestShiftTarget。
CLS会影响SEO吗？
Google建议良好的Core Web Vitals有助于在搜索中取得好成绩，并表示它们与其核心排名系统所希望奖励的内容一致；但它并不把它们称为直接的排名因素（Google搜索中心，2025年12月更新）。直接的影响体现在：页面跳动时，访客会失去阅读位置。