CLS (Cumulative Layout Shift)

CLS Cumulative Layout Shift é a métrica do Core Web Vitals do Google que mede a estabilidade visual de uma página durante o carregamento. Se imagens, anúncios ou banners empurram o conteúdo enquanto o usuário tenta ler ou clicar, isso conta como layout shift. O CLS soma todas essas mudanças inesperadas em um número único. A meta oficial é manter abaixo de 0,1 — acima disso, o Google considera ruim e penaliza no ranqueamento.

O que é CLS

O cumulative layout shift mede o quanto os elementos da página se mexem sozinhos depois que o usuário já está olhando para ela. O caso clássico: você abre um artigo, começa a ler, e de repente um banner de anúncio carrega no topo e empurra todo o texto para baixo. Você perde a linha onde estava. Pior: se ia clicar em um link, pode acabar clicando no anúncio.

Tecnicamente, o CLS é calculado multiplicando dois fatores: a fração da viewport afetada pelo deslocamento (impact fraction) e a distância máxima que os elementos se moveram (distance fraction). O resultado é um número entre 0 e 1, sem unidade. Quanto menor, melhor. Acima de 0,25 é considerado ruim. Entre 0,1 e 0,25 é “precisa melhorar”. Abaixo de 0,1 é bom.

O CLS entrou nos Core Web Vitals em 2020 e virou fator oficial de ranqueamento em 2021. É medido em campo (dados reais de usuários do Chrome) e em laboratório (testes sintéticos como Lighthouse). O Google usa principalmente o dado de campo, capturado via CrUX (Chrome User Experience Report), para decidir o impacto em SEO.

Diferente de LCP ou FID, que medem velocidade, o CLS mede percepção de estabilidade. É a única métrica do Core Web Vitals que pode piorar mesmo em sites rápidos — basta uma imagem sem dimensão definida ou uma fonte que carrega tarde.

O que causa layout shift

A causa número um são imagens sem largura e altura definidas no HTML. Quando o navegador encontra uma tag img sem dimensões, ele renderiza o conteúdo ao redor primeiro. Quando a imagem chega, ela ocupa espaço e empurra tudo. Solução: sempre incluir os atributos width e height no HTML, mesmo que use CSS responsivo.

A causa número dois são anúncios e iframes que carregam dinamicamente sem espaço reservado. Anúncios do Google AdSense, banners de afiliados, embeds do YouTube, pixels de remarketing — todos podem aparecer depois do conteúdo já estar visível. A solução é reservar o espaço com min-height ou aspect-ratio no CSS.

A causa número três são fontes web. Quando uma fonte custom carrega tarde, o navegador renderiza primeiro com uma fonte de fallback. Quando a fonte custom chega, o texto se reflowa para o novo tamanho — e o conteúdo abaixo se mexe. Soluções incluem font-display: optional, preload da fonte, ou size-adjust para casar métricas das fontes.

A causa número quatro são conteúdos injetados via JavaScript depois do load: notificações, banners de cookie, popups de newsletter, sliders. Tudo que aparece via JS depois que o HTML inicial renderizou pode causar shift se não tiver espaço reservado ou se for absolute-positioned em vez de flow-positioned.

A causa número cinco, mais sutil, são animações de CSS que mudam propriedades como height, width ou top em vez de transform. Mudanças de propriedades de layout custam reflow e contam como shift. Animações precisam usar transform e opacity para serem performáticas e não impactarem CLS.

Como medir CLS

A primeira ferramenta é o PageSpeed Insights, do próprio Google. Cole a URL e veja o CLS de campo (real users) e de laboratório. O relatório mostra os elementos específicos que mais contribuíram para o shift, com screenshots do antes e depois. É o ponto de partida para diagnóstico de qualquer site.

A segunda ferramenta é o Lighthouse, embutido no Chrome DevTools. Abra o site, F12, aba Lighthouse, gere um relatório. Diferente do PageSpeed, ele mostra dados de laboratório controlados — útil para reproduzir e debugar issues específicas. Os dados de campo continuam vindo do CrUX.

A terceira ferramenta é o Chrome DevTools direto, na aba Performance. Grave uma sessão de carregamento, observe a timeline de Layout Shifts. Cada barra vermelha é um shift, com detalhes de qual elemento moveu, quanto, e por quê. Mais técnico, mas é onde se mata bugs específicos de CLS.

A quarta ferramenta é o Search Console, na seção “Experiência → Core Web Vitals”. Mostra o CLS agregado do site em mobile e desktop, separa páginas em “Boas”, “Precisam melhorar” e “Ruins”. Depois de uma correção, é onde você acompanha se o site está saindo do vermelho ao longo das semanas.

Como reduzir CLS no WordPress

O primeiro passo é garantir que toda imagem tenha width e height. WordPress versão 5.5+ adiciona automaticamente para imagens da biblioteca de mídia, mas imagens hardcoded em widgets, page builders e custom HTML precisam de revisão manual. Plugins de page builder como Elementor têm opção de “definir dimensões” que precisa estar ligada.

O segundo passo é tratar fontes. Se você usa Google Fonts via plugin ou enfileiramento manual, garanta font-display: swap ou optional. Considere hospedar as fontes localmente em vez de usar a CDN do Google — reduz handshake DNS e dá controle sobre cache. Plugins como OMGF facilitam essa transição.

O terceiro passo é tratar embeds. Vídeos do YouTube, iframes do Spotify, mapas do Google — todos precisam de aspect-ratio definido. WordPress já faz isso para embeds nativos, mas elementos inseridos via shortcode customizado ou HTML bruto precisam ser revisados. Pode ser tão simples quanto envelopar em um div com aspect-ratio CSS.

O quarto passo é controlar JavaScript que injeta conteúdo. Banner de cookie deveria nascer fixo, não empurrar conteúdo. Popup de newsletter deveria usar overlay, não inserir no flow. Notificações no topo precisam ter espaço reservado desde o início. Plugins mal feitos costumam ser a fonte mais difícil de identificar.

O quinto passo é cache e otimização geral, porque CLS muitas vezes é sintoma de carregamento desestruturado. Combine com cache bem configurado, com priorização de carregamento dos elementos above-the-fold e com monitoramento dos Core Web Vitals. A FULL Services entrega o Perfmatter já licenciado e configurado dentro da stack profissional, com tuning específico para reduzir layout shifts em temas WordPress, otimização de fontes e controle granular de scripts. É a forma de manter CLS abaixo de 0,1 sem virar trabalho de ajuste manual a cada deploy.