Cumulative layout shift: encontrar e corrigir o CLS no celular

Cumulative layout shift explicado para celulares: os limites de CLS de 0,1 e 0,25, o que se move no mobile e como encontrar no DevTools e em dados de campo.

Neste artigo

O cumulative layout shift (CLS) mede o quanto o conteúdo visível se move de forma inesperada enquanto a página está aberta, e uma boa pontuação é 0,1 ou menos no 75º percentil das visitas (web.dev, abril de 2023). Valores acima de 0,25 são ruins. No celular, as causas comuns são imagens sem dimensões, anúncios e embeds sem espaço reservado, banners e avisos de cookies injetados no topo, fontes web atrasadas e animações que movem o layout. Encontre o elemento que se deslocou no DevTools e depois reserve o espaço dele antes que ele carregue.

O que é o cumulative layout shift?

O CLS é a maior rajada de deslocamentos de layout durante a vida de uma página, não a soma de todos eles. Cada deslocamento recebe uma pontuação igual a fração de impacto multiplicada pela fração de distância. A fração de impacto é a parte da área de visualização coberta pelos elementos que se moveram, e a fração de distância é a maior distância que um elemento percorreu dividida pela maior dimensão da área de visualização. Deslocamentos com menos de um segundo de intervalo são agrupados em uma janela de sessão de no máximo cinco segundos, e o CLS é a janela com a maior pontuação (web.dev). Deslocamentos que começam em até 500 ms depois de uma ação do usuário são excluídos (web.dev, Optimize CLS, fevereiro de 2025).

Classificação CLS (p75)
Bom 0,1 ou menos
Precisa melhorar Mais de 0,1 até 0,25
Ruim Mais de 0,25

São os limites do Google para «uma boa pontuação», e o web.dev recomenda verificar o 75º percentil separadamente para mobile e desktop.

Por que o CLS é mais difícil no celular

O mesmo movimento pontua mais alto em uma tela pequena, porque as duas frações são medidas em relação à área de visualização, e a maior dimensão de um celular é menor. Como ilustração com a fórmula acima: suponha que um banner de cookies de 80 px de altura apareça no topo da página e empurre tudo para baixo, numa área de visualização de 390 × 844 px cheia de conteúdo. Quase toda a área de visualização é afetada, então a fração de impacto fica perto de 1,0, e a fração de distância é 80 / 844 = 0,095. A pontuação fica em torno de 0,095, a um banner do limite de 0,1. É uma ilustração, e supõe que o conteúdo preenche a área de visualização.

Exemplo de cálculo do CLS: um banner de 80 px empurra o conteúdo em um celular de 390 × 844 px, resultando em 1,0 × 80/844 ≈ 0,095, logo abaixo do limite de 0,1 para uma boa pontuação

As causas são as mesmas do desktop, só que pontuadas em uma área menor, e o web.dev observa que os tamanhos de anúncio podem variar entre formatos de dispositivo, então um espaço reservado para o tamanho de desktop pode estar errado no celular.

O CLS também só é medido em alguns navegadores. A biblioteca web-vitals indica que onCLS() funciona apenas no Chromium, enquanto as outras funções também funcionam no Firefox e no Safari (README do web-vitals). O web-features 3.44.0 (outubro de 2026) mostra a API Layout Instability só no Chrome e no Edge. Então o CLS coletado em campo com essa biblioteca cobre os navegadores Chromium, e uma visita no Safari do iPhone não informa CLS por ela.

O que se move no mobile e como corrigir

Cada causa tem uma correção que reserva o espaço antes que o conteúdo chegue. Pelo guia do web.dev para otimizar o CLS (fevereiro de 2025):

Causa Correção
Imagens e vídeos sem dimensões Atributos width e height, ou aspect-ratio em CSS
Anúncios, embeds e iframes Reserve o espaço com min-height ou aspect-ratio; mantenha um espaço reservado quando nenhum anúncio retornar
Banners e avisos de cookies injetados na página Reserve o espaço com um placeholder, ou sobreponha o conteúdo para que ele não empurre a página
Fontes web atrasadas font-display: optional, uma fonte de reserva parecida, métricas de reserva com o mesmo tamanho
Animações Anime transform em vez de top, left ou box-shadow

Imagens e vídeos

Defina o tamanho intrínseco de cada imagem para que o navegador reserve a caixa antes de o arquivo chegar:

<img src="puppy.jpg" width="640" height="360" alt="Puppy with balloons">
img {
  height: auto;
  width: 100%;
}

Para imagens responsivas, o web.dev diz para manter a mesma proporção entre os candidatos de srcset, e para <picture> colocar width e height em cada <source> e no <img>. Um novo formato de imagem muda só o tamanho do arquivo, então não corrige isso; o padrão de <picture> está em WebP vs AVIF. O aspect-ratio é Baseline amplamente disponível desde março de 2024 (web-features 3.44.0).

Anúncios, embeds e banners

Reserve o espaço do slot com o menor tamanho que você espera, e use uma media query onde o tamanho muda no celular:

.ad-slot { min-height: 250px; }
@media (min-width: 768px) {
  .ad-slot { min-height: 90px; }
}

As duas alturas são exemplos; use os seus tamanhos de anúncio. O web.dev acrescenta três dicas: use o menor tamanho esperado como mínimo, mostre um placeholder em vez de encolher o espaço quando nenhum anúncio retornar, e coloque o conteúdo de carregamento tardio mais abaixo na área de visualização, porque conteúdo injetado perto do topo causa deslocamentos maiores. Para um aviso de cookies, faça dele uma sobreposição ou reserve a altura desde a primeira pintura, em vez de empurrar a página para baixo quando um script decide mostrá-lo.

Fontes web

Tanto o texto invisível quanto o texto sem estilo podem causar deslocamentos, porque o texto invisível ainda é posicionado com a fonte de reserva, segundo o web.dev. Ele sugere font-display: optional e uma fonte de reserva parecida, métricas de reserva com o mesmo tamanho e o pré-carregamento das fontes críticas. Os valores, o preload e o código de reserva estão no guia de font-display swap.

Animações e o botão voltar

Anime com transform, que não dispara layout; o web.dev observa que animações translate compostas não contam para o CLS. Torne também as páginas elegíveis ao cache de voltar/avançar, já que uma página restaurada aparece como o usuário a deixou, sem deslocamentos repetidos de carregamento. Isso não ajuda no primeiro carregamento.

Como encontrar deslocamentos de layout

Use ferramentas de laboratório para achar o elemento e dados de campo para ver se usuários reais o encontram. O web.dev lista estes caminhos:

  1. PageSpeed Insights: compare o CLS de campo (do Chrome UX Report) com o CLS de laboratório do Lighthouse. Uma grande diferença costuma apontar para deslocamentos depois do carregamento, que a execução de laboratório não vê.
  2. Lighthouse: os audits listam os elementos deslocados e as contribuições, mas muitas vezes mostram o elemento afetado e não a causa raiz.
  3. Painel Performance do DevTools: grave um trace e abra a faixa Layout shifts. As barras roxas marcam grupos de deslocamentos, um losango maior indica um deslocamento maior, e o resumo mostra o horário de início, a pontuação e os elementos deslocados. O insight Layout shift culprits lista o CLS total e as causas prováveis (web.dev).

Para ver qual elemento se deslocou para visitantes reais, adicione a versão de atribuição do web-vitals, que informa o alvo do maior deslocamento, o momento e o valor:

import {onCLS} from 'web-vitals/attribution';

onCLS(({value, rating, attribution}) => {
  console.log(rating, value, {
    target: attribution.largestShiftTarget,
    time: attribution.largestShiftTime,
    score: attribution.largestShiftValue,
  });
});

Deslocamentos dentro de iframes não podem ser medidos pelas APIs web, mas aparecem no Chrome UX Report, segundo o web.dev. Para saber como rodar o Lighthouse e as outras ferramentas, veja o guia de auditoria mobile com Lighthouse e o guia de teste de velocidade mobile.

Confira o layout em tamanhos de celular

Um layout que difere entre desktop e celular é mais fácil de notar em larguras de celular. O Mobile View Extension recarrega a aba com o user agent, o tamanho de tela e a densidade de pixels de um celular, para que você veja a versão mobile da página e observe o que se move durante o carregamento. Ele não mede o CLS nem nenhuma métrica de velocidade, e roda na sua conexão de desktop, então um banner ou um anúncio que desloca a página em um celular lento pode carregar rápido demais para você notar. Confirme com as ferramentas acima. Para outros motivos pelos quais uma página parece diferente no celular, veja por que um site parece diferente no mobile.

Perguntas frequentes

Qual é uma boa pontuação de CLS?

Uma boa pontuação de CLS é 0,1 ou menos, e acima de 0,25 é ruim, medidas no 75º percentil dos carregamentos de página (web.dev, abril de 2023). A faixa entre 0,1 e 0,25 precisa de melhoria.

O que causa deslocamento de layout no mobile?

As causas são imagens e vídeos sem dimensões, anúncios, embeds e iframes sem espaço reservado, banners e avisos de cookies injetados, fontes web que renderizam maiores ou menores que a fonte de reserva, e animações que alteram propriedades de layout. O mesmo movimento pontua mais alto no celular porque as frações são medidas em uma área de visualização menor.

Como encontro o que está causando o CLS?

Grave um trace no painel Performance do DevTools, abra a faixa Layout shifts e depois confira os elementos deslocados no resumo. Para visitantes reais, use a versão de atribuição do web-vitals para informar o largestShiftTarget.

O CLS afeta o SEO?

O Google recomenda boas Core Web Vitals para ter sucesso na Pesquisa e diz que elas estão alinhadas ao que seus principais sistemas de ranqueamento buscam recompensar; ele não as apresenta como fator de ranqueamento direto (Google Search Central, atualizado em dezembro de 2025). O efeito direto está nos visitantes que perdem o lugar quando a página pula.

Veja seu próximo site na versão mobile.

Adicione a extensão e abra prévias de aparelhos na mesma aba em que você já está trabalhando.