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

O que é o Cumulative Layout Shift (CLS)?

O Cumulative Layout Shift (CLS) representa a componente de «estabilidade visual» dos Core Web Vitals. O CLS mede o movimento da página enquanto o conteúdo renderiza ou quando surgem novos elementos. Dá por isso quando perde a linha no artigo que começou a ler, ou quando clica no botão errado porque este se moveu debaixo do dedo. Há quem lhe chame "content layout shift", mas o nome da métrica é Cumulative Layout Shift.

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

Uma boa pontuação de CLS situa-se entre 0 e 0,1. Entre 0,1 e 0,25 precisa de melhorias, e qualquer pontuação de CLS acima de 0,25 é considerada fraca. Para passar os Core Web Vitals no Cumulative Layout Shift, pelo menos 75% das visitas à página precisam de uma pontuação de CLS «boa». Esse é o p75 dos seus field data, com telemóvel e computador 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 os URLs com problemas por tipo. "Problema de CLS: mais de 0,1 (dispositivos móveis)" significa que precisa de melhorias, "Problema de CLS: mais de 0,25 (computador)" significa fraco, e ambos os limites existem para cada dispositivo. O Search Console calcula a média dos seus field data ao longo de uma janela deslizante. Por isso, uma correção não põe o relatório a verde no dia em que entra em produção: durante semanas, parte dos dados ainda reflete o site antigo.

O que lhe custa um layout shift

Uma página que salta parece avariada, mesmo quando tudo funciona.

• Visitantes e a marca: Um shift interrompe o que o visitante estava a fazer. Perde a linha que estava a ler ou toca no link errado, e há quem desista e saia. Um site que se move constantemente também parece mal construído, e isso reflete-se na empresa responsável.
• Acessibilidade: Os layout shifts afetam sobretudo quem vê apenas parte da página, por exemplo ao fazer zoom ou ao usar uma lupa de ecrã. Um único shift pode empurrar o texto que estava a ler para fora do ecrã.
• SEO e ranking na pesquisa: Os sistemas de classificação da Google usam os Core Web Vitals, e o CLS é um deles. É um fator de peso reduzido. A Google afirma que mostra primeiro o conteúdo mais relevante, e uma boa experiência de página ajuda quando várias páginas têm relevância semelhante.

Como é medido o CLS?

Os browsers comunicam os layout shifts através da Layout Instability API. Cole isto na consola e cada shift fica registado:

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 desse shift, e uma lista sources com os elementos que se moveram. Os shifts logo após um clique têm hadRecentInput definido como true. Ficam registados aqui, mas não contam para o CLS.

Cálculo do CLS

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

layout shift score = impact fraction * distance fraction

A fração de impacto corresponde a quanto do viewport os elementos em movimento tocam, somando onde estavam antes do shift e onde foram parar. A fração de distância corresponde à distância percorrida, como proporção da maior dimensão do viewport (num telemóvel, a altura).

Pense num elemento que cobre metade do viewport e desce 25% da altura do viewport. Juntos, o antes e o depois cobrem 75% do viewport. Isto resulta numa fração de impacto de 0,75 e numa fração de distância de 0,25, pelo que o shift pontua 0,75 * 0,25 = 0,1875. Um único shift como este ultrapassa 0,1 por si só. O CLS da página soma as pontuações destes shifts por janela de sessão, como se explica abaixo.

Layout shifts esperados vs. inesperados

Ao clicar num link para «carregar mais itens», espera-se que apareçam novos itens e que a página se mova. Por isso, apenas os layout shifts inesperados contam para o CLS. Qualquer shift que ocorra no espaço de 500 milissegundos após um clique, toque ou pressão de tecla fica de fora do cálculo; assim, um menu dropdown que abre com um clique não custa nada. O scroll não conta como interação; abordamos isso mais abaixo.

Sessões de layout shift

Quando o CLS foi lançado, somava todos os shifts durante todo o ciclo de vida da página. Páginas abertas durante muito tempo, como feeds com scroll infinito e single-page apps, continuavam a acumular 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 entre layout shifts. A sessão com a maior pontuação de CLS torna-se a pontuação final de CLS.

Suponha que a primeira sessão totaliza 0,095, a seguinte 0,15 e a última 0. A pontuação final de CLS é a mais alta das três: 0,15.

Causas comuns de CLS

Todos os layout shifts funcionam da mesma forma. Depois de a página renderizar, um elemento aumenta, diminui ou muda de posição, e tudo o que vem a seguir no layout move-se. Eis as causas habituais:

Imagens, vídeos e iframes sem dimensões

Elementos de media sem dimensões são uma das causas mais comuns de CLS. O browser só fica a saber o tamanho de uma imagem quando chegam os primeiros bytes do ficheiro. Até lá, sem um width e height (ou um aspect-ratio em CSS), não reserva espaço e a imagem não tem altura. Quando carrega, tudo o que está por baixo move-se para baixo.

Como imagens e elementos de media causam layout shift aborda imagens, vídeos e iframes sem dimensões, a armadilha do width: auto em CSS, art direction, discrepâncias em imagens responsivas, lazy loading e imagens de placeholder.

Substituição de web fonts

Enquanto a web font descarrega, a página renderiza o texto numa fonte de fallback. Quando a web font chega, o texto reorganiza-se. Diferentes larguras de letra e alturas de linha resultam em quebras de linha distintas, e todos os blocos abaixo desse parágrafo movem-se.

A auditoria do Lighthouse "Ensure text remains visible during webfont load" empurra para o font-display: swap. Para o CLS, isso não resolve nada isoladamente: o texto surge mais cedo, na fonte de fallback, mas a substituição continua a movê-lo. O que resolve é um fallback que ocupe o mesmo espaço, com overrides de métricas em @font-face como size-adjust e ascent-override. Depois, entregue a fonte mais cedo através de self-hosting e pré-carregamento das fontes críticas. O guia de diagnóstico e resolução inclui o código.

Animações e transições CSS

Ao animar top, left, width ou height, o browser recalcula o layout a cada frame. Cada um desses frames pode ser um layout shift. O transform e o opacity nunca acionam o layout; por isso, mova os elementos com essas propriedades. O artigo Layout shift causado por transições CSS explica como corrigir.

Anúncios, embeds e conteúdo injetado dinamicamente

Os anúncios carregam tarde e empurram o conteúdo para baixo. Um banner de cookies sobreposto à página não desloca nada, mas um que seja inserido no topo empurra a página inteira para baixo. Os pedidos AJAX fazem o mesmo quando injetam conteúdo sem reservar espaço. Em qualquer destes casos, entra na página algo que o browser desconhecia ao calcular o layout. Reserve o espaço logo à partida, por exemplo com um min-height no contentor. Para embeds de terceiros como o YouTube e o Google Maps, o padrão facade elimina o CLS por completo.

Layout shifts acionados pelo scroll

Um teste de carregamento no Lighthouse não faz scroll, pelo que não deteta esta causa de CLS. Cabeçalhos que se ocultam ao fazer scroll, efeitos de parallax e barras de navegação que encolhem animam frequentemente o top ou o height. O scroll não é uma interação excluída na especificação da Layout Instability; por isso, cada layout shift que ele despoleta conta para a pontuação de CLS. Use transform: translateY() em tudo o que se mover com o scroll. O artigo Como as animações acionadas por scroll causam CLS tem todos os detalhes.

Identificar e corrigir problemas de CLS

Comece pelos field data. Um teste com lab data só vê os primeiros segundos de carregamento da página, enquanto os visitantes fazem scroll, esperam pelos anúncios e continuam a ler. Analise o p75 do CLS para telemóvel e computador em separado: no CLS, o computador é muitas vezes o pior dos dois. O Google Search Console mostra quais os grupos de páginas que falham. Uma ferramenta de RUM como o CoreDash também regista que elemento se moveu, permitindo perceber se é a imagem de produto num template ou o bloco de anúncios noutro. Observe também a tendência. Um salto repentino indica normalmente que um novo deploy acrescentou algo, como um novo banner ou um espaço publicitário.

Depois, reproduza o problema no Chrome DevTools ou com a extensão Core Web Vitals Visualizer e descubra o que o faz mover. O diagnóstico passo a passo, tutoriais de ferramentas, correções de código para todas as causas e uma checklist de soluções rápidas estão em Identificar e corrigir problemas de Cumulative Layout Shift (CLS).

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

A Rakuten 24, uma loja online japonesa, otimizou uma landing page com tráfego elevado para os Core Web Vitals. Testou-a contra a versão original durante um mês, dividindo 50% do tráfego por cada versão. Para o CLS, reservou espaço para imagens com o aspect-ratio do CSS e para elementos com lazy loading através de min-height. O CLS da página otimizada foi 92,72% mais baixo. Terminou também o carregamento 0,4 segundos mais cedo no teste em telemóvel, com melhorias no FCP e TTFB. Face ao original, a página otimizada obteve:

• Mais 53,37% de receita por visitante
• Taxa de conversão 33,13% superior
• Valor médio por encomenda 15,20% superior
• Taxa de saída 35,12% inferior

O CLS foi a maior melhoria no teste, mas o tempo de carregamento, o FCP e o TTFB também melhoraram. Por isso, estes resultados pertencem ao conjunto da otimização. Não os cite como mérito exclusivo do CLS.

O que mostram os dados reais de CLS

No Chrome UX Report de agosto de 2026, 81,5% das origens tinham um bom CLS, uma subida face aos 80,1% registados em agosto de 2025.

No próprio corewebvitals.io, o CoreDash mede o CLS como o Core Web Vital com melhor desempenho. De todos os carregamentos de página, 92,8% obtêm a classificação «bom», quase sem diferença entre computador (92,8% bom) e telemóvel (92,7% bom). Ambos têm um p75 de 0, pelo que pelo menos três quartos dos carregamentos não tiveram qualquer layout shift.

Por toda a web, o CLS é melhor em telemóveis do que em computadores. É o inverso do LCP e do INP. O Web Almanac de 2025 apresenta os números, bem como a frequência das causas listadas acima:

• 81% dos sites em telemóvel e 72% em computador têm um bom CLS. Cerca de 9% dos sites em telemóvel e 10% em computador são fracos.
• 62% das páginas em telemóvel têm pelo menos uma imagem sem dimensões explícitas, descendo face aos 66% de 2024.
• 40% das páginas em telemóvel (44% em computador) têm animações non-composited.
• 87% das páginas em telemóvel utilizam pelo menos uma web font, e cerca de 12% fazem preload de uma (capítulo sobre fontes).

Guias relacionados

Estes guias aprofundam a identificação e correção de CLS:

• Identificar e corrigir problemas de CLS: diagnóstico passo a passo com demonstrações de ferramentas, correções de código para todas as causas e uma checklist de soluções rápidas.
• Como imagens e elementos de media causam layout shift: CLS resultante de imagens, vídeos e iframes sem dimensões, art direction, imagens responsivas, lazy loading e placeholders.
• Corrigir layout shifts provocados pelo dimensionamento automático de imagens: adicione dimensões corretas a imagens e contentores responsivos.
• Corrigir layout shifts causados por transições CSS: descubra que animações CSS acionam o layout e substitua-as por alternativas com composição (composited).
• Animações acionadas por scroll e o CLS: a causa de CLS que um teste de carregamento no Lighthouse não deteta, e como a corrigir.
• Alojamento próprio do Google Fonts: menos CLS no carregamento de fontes através de self-hosting, uso correto de font-display e preloading.
• Garantir que o texto permanece visível durante o carregamento de web fonts: font-display e metric overrides em fontes para evitar layout shifts de font-swap.
• Criar um widget de chat com Core Web Vitals perfeitos: estudo de caso sobre como integrar um widget de terceiros sem regressões no CLS, INP ou LCP.

A visão geral dos Core Web Vitals aborda as três métricas, e a checklist dos Core Web Vitals ajuda a auditar o seu site.