O que é Cumulative Layout Shift (CLS) e como corrigir

O que é Cumulative Layout Shift (CLS)?

O Cumulative Layout Shift (CLS) representa a parte de "estabilidade visual" das Core Web Vitals. O CLS mede o quanto a página se move enquanto o conteúdo é renderizado ou novos elementos aparecem. Você percebe o problema quando perde o ponto em que estava lendo um artigo, ou quando clica no botão errado porque ele se moveu sob o dedo. Às vezes chamam a métrica de "content layout shift", mas o nome oficial é Cumulative Layout Shift.

O que é uma boa pontuação de Cumulative Layout Shift (CLS)?

Uma boa pontuação de CLS fica entre 0 e 0,1. Entre 0,1 e 0,25, ela precisa de melhorias, e qualquer pontuação acima de 0,25 é considerada ruim. Para passar nas Core Web Vitals no Cumulative Layout Shift, pelo menos 75% das visitas à página precisam ter uma pontuação "boa". Esse é o p75 do seu field data, com mobile e desktop medidos separadamente. O CLS não tem unidade: é uma pontuação, enquanto o LCP e o INP são tempos.

O relatório de Core Web Vitals no Google Search Console agrupa as URLs com falha por problema. "CLS issue: more than 0.1 (mobile)" significa que precisa de melhorias, "CLS issue: more than 0.25 (desktop)" significa ruim, e ambos os limites existem para cada dispositivo. O Search Console calcula a média do field data em uma janela contínua. Por isso, uma correção não deixa o relatório verde no dia em que entra no ar: durante semanas, parte do que ele mostra ainda reflete o site antigo.

O que um layout shift custa para você

Uma página que fica pulando parece quebrada, mesmo quando tudo nela funciona.

• Visitantes e a marca: Um deslocamento interrompe o que o visitante estiver fazendo. Ele perde a linha que estava lendo ou toca no link errado, e parte dos usuários desiste e vai embora. Um site que fica se movendo também parece mal construído, e isso queima a empresa por trás dele.
• Acessibilidade: Os layout shifts pesam ainda mais quando você vê apenas parte da página, como ao dar zoom ou usar um ampliador de tela. Um único deslocamento pode jogar o texto que você estava lendo para fora da tela.
• SEO e posicionamento na busca: Os sistemas de ranqueamento do Google usam as Core Web Vitals, e o CLS é uma delas. É um fator de peso pequeno. O Google afirma que prioriza o conteúdo mais relevante, e uma boa experiência de página ajuda no desempate quando muitas páginas têm relevância similar.

Como o CLS é medido?

Os navegadores relatam os layout shifts por meio da Layout Instability API. Cole isto no console e todo deslocamento será registrado:

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('Layout shift:', entry);
  }
}).observe({type: 'layout-shift', buffered: true});

Cada entrada tem um value, que é a pontuação daquele deslocamento, e uma lista sources com os elementos que se moveram. Deslocamentos logo após um clique têm hadRecentInput definido como true. Eles aparecem no log aqui, mas não contam para o CLS.

Como calcular o CLS

Cada layout shift recebe sua própria pontuação:

pontuação do layout shift = fração de impacto * fração de distância

A fração de impacto mede quanto do viewport os elementos em movimento ocupam, considerando onde estavam antes do deslocamento e onde foram parar. A fração de distância mede a distância que eles se moveram, como proporção da maior dimensão do viewport (em um celular, a altura).

Considere um elemento que ocupa metade do viewport e desce 25% da altura do viewport. Somando o antes e o depois, ele afeta 75% do viewport. Isso resulta em uma fração de impacto de 0,75 e uma fração de distância de 0,25; portanto, o deslocamento pontua 0,75 * 0,25 = 0,1875. Um único deslocamento como esse já fica acima de 0,1 por conta própria. O CLS da página soma essas pontuações por janela de sessão, conforme explicado abaixo.

Layout shifts esperados vs. inesperados

Ao clicar em um link para carregar mais itens, você espera que novos itens apareçam e a página se mova. Por isso, apenas layout shifts inesperados contam para o CLS. Qualquer deslocamento dentro de 500 milissegundos após um clique, toque ou tecla pressionada fica fora do cálculo, de modo que um menu dropdown aberto com um clique não afeta a pontuação. A rolagem não conta como entrada — falaremos mais disso adiante.

Sessões de layout shift

Quando o CLS foi lançado, ele somava cada deslocamento durante toda a vida útil da página. Páginas que ficavam abertas por muito tempo, como rolagens infinitas e single-page apps, continuavam acumulando pontuação. Desde junho de 2021, o CLS é calculado em sessões. Cada sessão dura no máximo 5 segundos e termina após um intervalo de 1 segundo sem novos deslocamentos. A sessão com a maior pontuação de CLS se torna a pontuação final.

Se a primeira sessão somar 0,095, a seguinte 0,15 e a última 0, a pontuação final de CLS será a maior das três: 0,15.

Causas comuns de CLS

Todo layout shift funciona do mesmo jeito. Depois que a página renderiza, um elemento aumenta, diminui ou muda de posição, e tudo o que vem depois dele no layout se move junto. Os motivos mais comuns são estes:

Imagens, vídeos e iframes sem dimensões

Mídias sem tamanho definido estão entre as causas mais frequentes de CLS. O navegador só descobre o tamanho da imagem quando os primeiros bytes do arquivo chegam. Até lá, sem width e height (ou um aspect-ratio no CSS), ele não reserva espaço e a imagem fica sem altura. Quando ela carrega, tudo o que está abaixo dela desce.

O guia Como imagens e mídias causam layout shift aborda imagens, vídeos e iframes sem tamanho, a armadilha do width: auto no CSS, direção de arte, divergências em imagens responsivas, lazy loading e imagens de placeholder.

Troca de web fonts

Enquanto a web font é baixada, a página renderiza o texto com uma fonte de fallback. Quando a web font chega, o texto sofre reflow. Larguras de letras e alturas de linha diferentes causam quebras de linha distintas, e cada bloco abaixo daquele parágrafo se move.

A auditoria "Ensure text remains visible during webfont load" do Lighthouse empurra você para o font-display: swap. Para o CLS, isso não resolve nada sozinho: o texto aparece antes, na fonte de fallback, mas a troca continua deslocando o conteúdo. O que resolve é usar um fallback que ocupe o mesmo espaço, com ajustes de métricas na regra @font-face como size-adjust e ascent-override. Depois, entregue a fonte mais rápido fazendo a auto-hospedagem e o preload das fontes críticas. O guia de diagnóstico e correção traz o código completo.

Animações e transições CSS

Ao animar top, left, width ou height, o navegador recalcula o layout a cada frame. Cada um desses frames pode gerar um layout shift. As propriedades transform e opacity nunca acionam o layout; por isso, mova os elementos com elas. O artigo Layout shift causado por transições CSS mostra a correção passo a passo.

Anúncios, embeds e conteúdo inserido dinamicamente

Anúncios demoram a carregar e empurram o conteúdo para baixo. Um banner de cookies sobreposto à página não desloca nada, mas um banner inserido no topo empurra a página inteira para baixo. Requisições AJAX fazem o mesmo quando injetam conteúdo sem reservar espaço. Em cada um desses casos, surge algo na página que o navegador desconhecia quando montou o layout. Reserve o espaço com antecedência, por exemplo com min-height no container. Para embeds de terceiros como YouTube e Google Maps, o padrão facade elimina o CLS por completo.

Layout shifts ativados por rolagem

O teste de carregamento de página do Lighthouse não rola a tela, por isso não detecta essa causa de CLS. Cabeçalhos que se ocultam na rolagem, efeitos parallax e barras de navegação que encolhem costumam animar top ou height. A rolagem não é uma entrada de exclusão na especificação da Layout Instability, então todo layout shift disparado por ela conta na sua pontuação de CLS. Use transform: translateY() para qualquer elemento que se mova na rolagem. O guia Como animações ativadas por rolagem causam CLS traz os detalhes.

Como identificar e corrigir problemas de CLS

Comece pelo field data. Um teste de laboratório vê apenas os primeiros segundos do carregamento da página, enquanto os visitantes rolam a tela, esperam os anúncios e continuam lendo. Verifique o p75 do CLS para mobile e desktop separadamente: no caso do CLS, o desktop costuma ser o pior dos dois. O Google Search Console mostra quais grupos de páginas estão falhando. Uma ferramenta de RUM como o CoreDash também registra qual elemento se deslocou, para você ver se foi a imagem do produto em um modelo ou o espaço de anúncio em outro. Acompanhe a tendência também. Um salto repentino geralmente significa que uma release adicionou algo novo, como um banner ou espaço de anúncio.

Depois, reproduza o problema no Chrome DevTools ou com a extensão Core Web Vitals Visualizer para encontrar o que está causando o deslocamento. O diagnóstico passo a passo, orientações sobre ferramentas, correções de código para cada causa e um checklist rápido estão em Como identificar e corrigir problemas de Cumulative Layout Shift (CLS).

Estudo de caso: o teste A/B de Core Web Vitals da Rakuten 24

A Rakuten 24, uma loja online japonesa, otimizou uma landing page de alto tráfego com foco nas Core Web Vitals. Eles rodaram um teste comparando a nova versão com a original durante um mês, com 50% do tráfego em cada uma. Para o CLS, reservaram espaço para imagens usando aspect-ratio no CSS e para elementos com lazy loading usando min-height. O CLS da página otimizada foi 92,72% menor. Ela também terminou de carregar 0,4 segundo antes no teste de carregamento mobile, com melhorias no FCP e no TTFB. Em comparação com a versão original, a página otimizada teve:

• 53,37% mais receita por visitante
• 33,13% de aumento na taxa de conversão
• 15,20% de aumento no ticket médio
• 35,12% de redução na taxa de saída

O CLS foi o ponto de maior evolução no teste, mas o tempo de carregamento, o FCP e o TTFB também melhoraram. Portanto, esses resultados pertencem ao conjunto da otimização. Não os cite como um ganho gerado apenas pelo CLS.

O que os dados reais de CLS mostram

No Chrome UX Report de agosto de 2026, 81,5% das origens tinham um CLS bom, acima dos 80,1% registrados em agosto de 2025.

No próprio corewebvitals.io, o CoreDash aponta o CLS como a métrica das Core Web Vitals com melhor desempenho. De todos os carregamentos de página, 92,8% pontuam como "bom", praticamente sem diferença entre desktop (92,8% bom) e mobile (92,7% bom). Ambos têm um p75 de 0, ou seja, pelo menos três quartos dos carregamentos não tiveram nenhum layout shift.

Na web em geral, o CLS é melhor no mobile do que no desktop. É o oposto do LCP e do INP. O Web Almanac de 2025 traz os números, além da frequência com que as páginas apresentam as causas listadas acima:

• 81% dos sites mobile e 72% dos sites desktop têm um CLS bom. Cerca de 9% dos sites mobile e 10% dos desktop estão na faixa ruim.
• 62% das páginas mobile têm pelo menos uma imagem sem dimensões explícitas — uma queda em relação aos 66% de 2024.
• 40% das páginas mobile (44% no desktop) têm animações non-composited.
• 87% das páginas mobile usam pelo menos uma web font, e cerca de 12% fazem o preload de alguma (capítulo sobre fontes).

Guias relacionados

Estes guias vão mais a fundo na identificação e correção do CLS:

• Como identificar e corrigir problemas de CLS: diagnóstico passo a passo com orientações sobre ferramentas, correções de código para cada causa e um checklist rápido.
• Como imagens e mídias causam layout shift: CLS decorrente de imagens, vídeos e iframes sem tamanho, direção de arte, imagens responsivas, lazy loading e placeholders.
• Como corrigir o layout shift causado por imagens com redimensionamento automático: adicione dimensões corretas a imagens e containers responsivos.
• Como corrigir layout shift causado por transições CSS: localize animações CSS que acionam o layout e substitua-as por alternativas com composição.
• Animações ativadas por rolagem e o CLS: a causa de CLS que o teste de carregamento do Lighthouse não detecta, e como corrigi-la.
• Hospede o Google Fonts no próprio servidor: reduza o CLS no carregamento de fontes usando auto-hospedagem, o font-display correto e preloading.
• Garanta que o texto permaneça visível durante o carregamento de web fonts: uso de font-display e ajustes de métricas de fonte para evitar layout shifts na troca de fontes.
• Crie um widget de chat com Core Web Vitals perfeitas: um estudo de caso sobre como adicionar um widget de terceiros sem regressões no CLS, INP ou LCP.

A visão geral das Core Web Vitals cobre todas as três métricas, e o checklist de Core Web Vitals ajuda você a auditar seu site.