请避免出现大幅度的布局偏移-怎么处理?

做网站SEO或者用PageSpeed Insights、Lighthouse检查网页时，经常会看到一条提示：

请避免出现大幅度的布局偏移。

英文一般对应：

Avoid large layout shifts

很多站长第一次看到会比较迷惑。

网站明明可以正常打开；

图片也能显示；

文章没有报错；

为什么还会提示“布局偏移”？

其实这个问题和页面能不能打开没有直接关系。

它主要检测的是：

页面加载过程中，已经显示出来的内容会不会突然移动位置。

例如你刚准备点击“查看详情”，上方突然加载了一张Banner，按钮被往下推；

正在阅读文章，图片加载完成后正文突然整体下移；

准备点击菜单，网页字体加载以后文字宽度变化，按钮位置发生移动。

这种现象就属于布局偏移。

Google把它纳入Core Web Vitals，也就是核心网页指标，并使用CLS（Cumulative Layout Shift，累计布局偏移）衡量页面视觉稳定性。目前Google建议，在至少75%的真实网页访问中，把CLS控制在 0.1或以下；0.1—0.25属于需要改进，超过0.25通常属于较差。

所以看到“请避免出现大幅度的布局偏移”，真正应该解决的是：

提前给页面元素留好空间，不要让后加载的内容把已经显示出来的内容推来推去。

下面可以按照实际网站排查。

第一：先理解CLS是什么，别把它当成页面速度

CLS属于Core Web Vitals，但它测的不是页面加载用了几秒。

Google目前的三项核心网页指标分别是：

LCP：主要内容加载速度，建议2.5秒以内；
INP：用户交互响应速度，建议200毫秒以内；
CLS：视觉稳定性，建议0.1以内。

所以一个网页完全可能出现：

加载速度很快
LCP很好

但是：

CLS很差

因为页面虽然加载快，元素却不断跳动。

比如：

页面0.5秒已经显示标题和正文；

1秒后顶部广告加载；

整篇文章向下移动200px。

这就是典型的CLS问题。

因此优化时不要只想着：

图片压缩一下。

真正要查的是：

谁在页面加载以后改变了原来的布局空间。

第二：最常见原因之一——图片没有提前设置宽高

这是CLS问题里非常常见的一种。

例如页面代码：

<img src="/images/product.webp" alt="产品图片">

浏览器刚读取HTML时，只知道：

这里有张图片。

却不知道图片最终到底：

300px高；

500px高；

还是800px高。

于是浏览器可能先把下面正文排到图片位置附近。

等图片加载完成以后，才发现：

原来这里需要500px高度。

结果正文瞬间被推下去。

Google目前列出的CLS常见原因中，“图片没有尺寸”就属于非常典型的问题。

怎么修改？

最简单的方法，就是给图片提供明确的width和height：

<img
  src="/images/product.webp"
  alt="产品图片"
  width="1200"
  height="675"
>

浏览器会根据宽高比例提前预留空间。

响应式网站不用担心写了width以后图片不能缩放。

CSS仍然可以：

img {
  max-width: 100%;
  height: auto;
}

这样图片仍然会自适应。

关键不是把图片显示尺寸锁死。

而是提前告诉浏览器：

这张图片是什么比例。

第三：如果不知道实际图片高度，可以使用aspect-ratio预留比例

例如网站大量使用16:9文章封面。

可以直接设置：

.article-image {
  width: 100%;
  aspect-ratio: 16 / 9;
  object-fit: cover;
}

这样即使图片本身还没有加载出来，浏览器已经知道：

这里必须保留16:9空间。

等图片真正下载完成以后，它只是填进去。

不会再把下面的正文突然往下推。

这种处理方式特别适合：

文章缩略图；

产品图片；

轮播图；

视频封面；

卡片图片。

所以检查CLS时，第一个建议就是：

把页面里所有没有尺寸信息的图片找出来。

第四：广告位、iframe、视频嵌入，也要提前占位置

第二种特别常见的问题是：

广告；

地图；

视频；

第三方表单；

iframe；

社交媒体组件。

比如文章正文中间有一个广告位。

页面刚打开时广告还没有返回。

正文直接连在一起。

几秒以后广告加载成功：

原来需要250px高度

于是下面内容整体被推下去。

Google同样把没有预留尺寸的广告、嵌入内容和iframe列为CLS常见原因。

解决方法其实和图片一样：

提前留位置。

例如：

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

或者：

.video-wrapper {
  width: 100%;
  aspect-ratio: 16 / 9;
}

iframe再填进去。

真正应该避免的是：

加载前高度0
↓
加载完成高度400px

这几乎天然就会产生布局变化。

第五：轮播图Banner是企业官网CLS的高发区

企业官网首页特别喜欢：

大Banner；

Swiper轮播；

产品轮播；

案例轮播。

而这类组件特别容易触发CLS。

比如页面刚加载：

Banner容器高度：0

JavaScript运行以后读取图片尺寸：

Banner高度：600px

整个首页瞬间向下移动600px。

这类问题在视觉上非常明显。

修复时应该提前给轮播区域设置：

.hero-slider {
  min-height: 520px;
}

更推荐根据实际比例：

.hero-slider {
  aspect-ratio: 16 / 7;
}

然后内部图片：

.hero-slider img {
  width: 100%;
  height: 100%;
  object-fit: cover;
}

这样无论Swiper什么时候初始化，外层空间已经存在。

还有一种很典型：

用户打开网站以后，顶部突然出现：

Cookie通知；

活动公告；

APP下载提醒；

登录提示。

整个页面瞬间向下移动。

Lighthouse官方示例里就专门展示过类似Cookie通知导致页面内容发生移动的问题。Google给出的处理思路包括：

提前保留空间，或者使用fixed定位，让提示层覆盖显示而不改变其他内容布局。

例如原来：

.cookie-banner {
  position: sticky;
  top: 0;
}

它进入页面文档流以后，会占据高度。

可以根据实际设计调整为：

.cookie-banner {
  position: fixed;
  left: 0;
  right: 0;
  bottom: 0;
}

这样它会浮在页面底部。

不会把正文重新往下推。

当然要注意：

不要挡住主要按钮和正文。

第七：动态插入内容，是WordPress网站特别容易出现的问题

WordPress常见：

第八：字体加载也会导致页面“突然变形”

这个问题比较隐蔽。

例如网站使用：

阿里普惠体；

思源黑体；

Google Fonts；

自定义Web Font。

网页刚打开时，字体文件还没下载。

浏览器先用系统默认字体显示。

1秒以后Web Font加载完成。

新字体和默认字体的：

字符宽度；

字高；

行高

不同。

于是标题可能从：

一行

变成：

两行

下面内容整体往下移动。

Google也把Web Fonts列为CLS常见来源之一。

比较常见的优化方向包括：

预加载关键字体；

减少字体文件数量；

合理设置font-display；

尽量选择尺寸接近的fallback字体；

必要时使用size-adjust等CSS字体度量参数降低字体切换差异。

例如：

@font-face {
  font-family: "MyFont";
  src: url("/fonts/myfont.woff2") format("woff2");
  font-display: swap;
}

如果网站字体很多，而且CLS问题集中发生在标题区域，就值得重点排查这一项。

第九：懒加载本身没问题，关键是有没有预留尺寸

很多站长发现图片使用了：

loading="lazy"

就怀疑：

是不是Lazy Load导致CLS？

Lazy Load本身并不是问题。

真正的问题通常是：

懒加载图片没有提前占空间。

例如：

<img loading="lazy" src="image.webp">

如果图片没有宽高信息，滚动到它附近时图片突然加载，就可能推动下面内容。

如果写成：

<img
  loading="lazy"
  src="image.webp"
  width="1200"
  height="675"
>

浏览器已经预留空间。

懒加载仍然可以正常使用。

所以不需要为了CLS把全站Lazy Load全部关掉。

第十：动画不要通过改变top、left、width、height来移动布局

页面还有一种偏移来自动画。

例如鼠标经过卡片以后：

.card:hover {
  width: 110%;
}

或者：

.element {
  position: relative;
  top: 20px;
}

如果动画改变真正的布局尺寸，就可能影响周围元素。

更合适的方式通常是使用：

transform

例如：

.card:hover {
  transform: scale(1.05);
}

transform通常不会重新计算周围页面布局，因此更适合视觉动画。

尤其：

顶部导航；

卡片悬停；

按钮；

图片放大

这些效果，不要通过改变真正的盒子尺寸制造页面跳动。

第十一：怎么找到到底是哪一个元素发生了布局偏移？

不要只看PageSpeed给出的CLS数字。

真正解决问题，需要定位元素。

方法一：PageSpeed Insights

直接测试URL。

重点看：

Core Web Vitals；

Diagnostics；

Avoid large layout shifts。

如果Lighthouse识别出明显发生移动的元素，会列出相关节点。

Google官方也明确说明，Lighthouse的“Avoid large layout shifts”审计会帮助识别发生位移的页面元素。

方法二：Chrome DevTools

打开：

F12
→ Performance

录制页面加载过程。

在Performance记录里查找：

Layout Shift

事件。

可以进一步看到：

哪个元素发生了移动；

什么时候移动；

大概贡献多少CLS。

这是开发人员定位问题非常好用的方法。

方法三：Search Console核心网页指标

如果问题已经影响大量真实用户，还应该看：

Google Search Console
→ 核心网页指标

这里使用真实用户数据，可以看到：

哪些URL组存在CLS问题。

第十二：为什么PageSpeed测试CLS正常，Search Console却说CLS差？

这个问题非常常见。

原因在于：

实验室数据和真实用户数据不是一回事。

Lighthouse测试只是一次模拟加载。

Search Console中的Core Web Vitals则主要来自真实用户体验数据。

Google对CLS的建议也是按照真实访问的第75百分位判断，并分别看移动端和桌面端。

而且Lighthouse主要分析页面加载阶段。

有些内容：

Cookie；

广告；

聊天插件；

弹窗

可能在页面加载完成以后才出现。

Google官方也提醒，这类加载之后发生的布局偏移可能真实影响用户，却不一定在一次Lighthouse测试里全部暴露。

所以实际应该：

PageSpeed / Lighthouse
→ 找技术问题

Search Console / CrUX
→ 看真实用户是否仍然受影响

两个一起用。

第十三：移动端CLS差，桌面正常，应该重点查什么？

这种情况也特别多。

通常重点检查：

响应式图片；

移动Banner；

移动端菜单；

广告；

顶部APP下载条；

浮动按钮；

字体换行；

隐藏/显示组件。

比如桌面标题只有一行：

企业官网SEO服务解决方案

手机屏幕变窄后：

字体加载前两行；

字体加载后变三行。

整个正文继续下移。

还有：

桌面端不显示APP下载条；

移动端加载以后顶部增加80px。

所以CLS一定要分：

桌面端

和：

移动端

分别检查。

不要只在自己的PC浏览器里看网页觉得没跳，就认为问题已经不存在。

第十四：WordPress网站出现CLS，可以先排查这些位置

如果使用WordPress，建议优先检查：

1. Featured Image

文章特色图片有没有width和height。

主题轮播组件有没有预留高度。

3. Elementor/页面构建器组件

部分组件可能等JS执行后才确认高度。

4. 广告插件

广告位加载前有没有Placeholder。

提示条是不是直接把页面整体推下去。

6. 聊天工具

在线客服是否动态插入页面空间。

7. SEO/相关文章插件

相关推荐是否在正文加载以后插入。

8. Web Font

主题是否一次加载很多字体和字重。

9. Lazy Load

图片、iframe和视频有没有提前预留尺寸。

很多WordPress CLS问题，最后都能在这些位置找到原因。

第十五：一个实际案例：文章页CLS 0.36应该怎么修？

假设一个网站PageSpeed数据显示：

CLS：0.36

属于较差水平。

查看Performance以后发现三个主要问题。

第一个问题：文章头图没有尺寸

修改：

<img src="cover.webp">

为：

<img
  src="cover.webp"
  width="1600"
  height="900"
>

第二个问题：正文顶部广告后加载

给广告容器预留：

.article-ad {
  min-height: 280px;
}

第三个问题：顶部Cookie条把网页向下推

改成固定底部显示，或者在首屏渲染时提前保留它需要的高度。

修复以后重新测试。

CLS例如从：

0.36

下降到：

0.07

这时候才算真正进入Google建议的“良好”范围。

注意这里的数字只是示例。

具体网站需要用自己的PageSpeed和真实用户数据验证。

第十六：CLS优化和SEO排名是什么关系？

这里也不要过度理解。

Core Web Vitals属于Google页面体验的一部分。

Google明确建议网站实现良好的Core Web Vitals，以改善用户体验并有利于搜索表现，但同时也强调，好的Core Web Vitals并不能保证页面一定获得靠前排名。

所以：

CLS 0

不等于：

关键词第一名

搜索排名还要继续看：

内容；

第十七：可以直接按这份CLS检查清单修改

看到：

请避免出现大幅度的布局偏移

可以按照下面顺序排查。

图片

图片有没有width和height？
响应式图片有没有明确比例？
Lazy Load图片有没有预留空间？

视频和iframe

YouTube/B站视频有没有固定比例？
地图iframe有没有尺寸？
第三方组件有没有Placeholder？

首页轮播有没有提前设置高度？
移动端Banner高度是否稳定？

动态内容

广告是不是加载以后才撑开页面？
相关文章有没有动态插入？
登录条、公告条有没有把正文向下推？

字体

是否加载大量Web Font？
字体切换有没有明显换行？
关键字体是否需要预加载？

弹窗和Cookie

是否占用文档流？
能不能使用fixed覆盖？
或者提前预留空间？

动画

有没有通过width、height、top、left制造位移？
能不能改成transform？

数据验证

Lighthouse具体是哪一个元素发生偏移？
Chrome DevTools里哪个Layout Shift最大？
Search Console真实用户CLS是否仍然不达标？

逐项检查以后，通常能够找到主要贡献元素。

最后：“避免大幅度布局偏移”的核心，就一句话——加载之前把位置留出来

Google目前列出的CLS高发原因其实非常集中：

没有尺寸的图片、没有预留空间的广告和iframe、动态插入内容，以及Web字体变化。

它们背后的共同问题都是：

浏览器一开始不知道这个元素需要多少空间
↓
先把后面的内容排上来
↓
元素突然加载
↓
重新计算布局
↓
页面发生跳动

因此最有效的解决逻辑就是：

提前确定尺寸
↓
预留空间
↓
内容加载
↓
填充原来的位置

对于图片，使用width、height或者aspect-ratio。

对于广告和iframe，设置固定尺寸或min-height。

对于Banner，提前确定容器比例。

对于Cookie和悬浮组件，尽量不要加载以后推动已有内容。

对于字体，则减少字体切换造成的尺寸差异。

最后再用：

PageSpeed Insights + Lighthouse + Chrome DevTools + Search Console核心网页指标

一起验证。

只要让页面在加载过程中做到：

东西可以慢一点出现，但已经出现的内容不要突然乱跑，

CLS问题基本就抓住核心了。

而对于企业网站来说，这不仅是为了把PageSpeed里的红色提示变绿色。

请避免出现大幅度的布局偏移——怎么处理？