As melhores dicas para corrigir problemas de CLS no Search Console

Table of contents

CLS: O contexto

O Cumulative Layout Shift mede movimentos inesperados de layout. Toda vez que um elemento visível muda de posição enquanto a página carrega ou é interagida, uma pontuação de deslocamento de layout é calculada. A pontuação acumulada é o CLS.

Causas comuns:

• Imagens ou iframes sem atributos explícitos de width e height
• Anúncios que se expandem depois que o conteúdo ao redor já foi renderizado
• Conteúdo injetado dinamicamente (banners, avisos de cookies, widgets de chat) inserido acima do conteúdo existente
• Fontes web que causam um flash e reflow quando carregam (FOUT/FOIT)
• JavaScript de terceiros que adiciona elementos de UI após o render inicial

Relacionado: Como corrigir problemas de LCP no Search Console

Medindo o CLS

Google Search Console

O relatório de Core Web Vitals do Search Console é o ponto de partida. Ele exibe páginas sinalizadas como “Ruim” (CLS ≥ 0,25) ou “Precisa de melhorias” (0,1–0,25), agrupadas por tipo de problema. Use este relatório para obter a lista de URLs afetadas.

PageSpeed Insights

O PageSpeed Insights (PSI) mostra tanto dados de laboratório (simulação Lighthouse) quanto dados de campo de usuários reais via Chrome UX Report (CrUX). Os dados de campo importam mais para fins de ranking — eles refletem experiências reais de usuários, não apenas um teste sintético.

O PSI só simula o viewport inicial no carregamento, por isso pode não capturar CLS acionado por rolagem ou interação do usuário. Para esses casos, use o Chrome DevTools.

Chrome DevTools e a extensão Web Vitals

A extensão Web Vitals do Chrome (mantida pelo Google) exibe pontuações CLS em tempo real enquanto você rola e interage com uma página. É a maneira mais rápida de reproduzir deslocamentos de layout manualmente. O painel Performance do Chrome DevTools também destaca registros de deslocamento de layout com anotações mostrando quais elementos se moveram e quanto.

Corrigindo problemas de CLS

Adicionar width e height a todas as imagens e iframes

Esta é a correção de maior impacto para a maioria dos sites. Sem dimensões explícitas, o navegador não sabe quanto espaço reservar enquanto uma imagem carrega, então o conteúdo abaixo é empurrado para baixo quando a imagem aparece.

<!-- Ruim: sem dimensões -->
<img src="photo.jpg" alt="…">

<!-- Bom: dimensões explícitas permitem ao navegador reservar espaço -->
<img src="photo.jpg" alt="…" width="800" height="450">

O CSS moderno (aspect-ratio) alcança o mesmo efeito para imagens responsivas, mas definir explicitamente os atributos width e height no HTML é a abordagem mais confiável e é tratada automaticamente pela maioria dos frameworks modernos e pipelines de imagens de CMS.

Reservar espaço para anúncios

Anúncios são a causa mais comum de CLS alto em sites monetizados. Redes de anúncios servem tamanhos dinâmicos e, se nenhum espaço for reservado, a página reflui quando o anúncio carrega.

1. Reserve um container fixo (min-height correspondendo ao tamanho de anúncio mais comum) antes do carregamento da tag de anúncio.
2. Não recolha o container se nenhum anúncio for servido — um espaço reservado vazio evita um segundo reflow.
3. Tenha especial atenção com anúncios colocados próximos ao topo do viewport. Anúncios não fixos inseridos acima da dobra causam as piores pontuações CLS.
4. Use dados históricos de impressão da sua rede de anúncios para determinar quais tamanhos de anúncio são mais comuns para cada posição e dimensione o container adequadamente.

Evitar inserir conteúdo acima do conteúdo existente

Banners de consentimento de cookies, prompts de notificação e widgets de chat que carregam de forma assíncrona e aparecem acima do conteúdo existente são uma fonte frequente de CLS. Opções:

• Carregue-os em um overlay de posição fixa (eles não afetam o fluxo do documento).
• Pré-aloque espaço no layout se precisarem aparecer inline.
• Para banners de cookies especificamente, considere posicionamento na parte inferior da tela — evita CLS completamente e é igualmente compatível com regulamentações.

Corrigir o carregamento de fontes web (FOIT e FOUT)

FOIT (Flash of Invisible Text) ocorre quando o navegador oculta o texto até que uma fonte personalizada carregue. FOUT (Flash of Unstyled Text) ocorre quando uma fonte de fallback é mostrada primeiro e depois trocada — a diferença nas métricas de fonte causa um deslocamento de layout.

A correção é font-display: swap combinado com <link rel="preload"> para fontes críticas:

<link rel="preload" href="/fonts/my-font.woff2" as="font" type="font/woff2" crossorigin>

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

font-display: swap causa FOUT (texto visível mas sem estilo) em vez de FOIT (texto invisível), o que é melhor para CLS porque o texto fica visível imediatamente. Para reduzir ainda mais o impacto da troca na métrica, use a propriedade CSS size-adjust para corresponder as métricas da fonte de fallback à fonte personalizada — isso minimiza o reflow quando a fonte personalizada entra em ação.

JavaScript de terceiros

Scripts de terceiros (botões de compartilhamento, widgets de comentários, chat ao vivo, popups de analytics) carregam de forma assíncrona e frequentemente injetam elementos de UI após a página já ter sido renderizada. Para minimizar seu impacto no CLS:

• Coloque elementos visuais de terceiros abaixo do viewport inicial quando possível — conteúdo mais abaixo na página tem mais tempo para carregar antes do usuário chegar a ele.
• Pré-defina as dimensões do container antes de o script executar, para que o navegador já saiba quanto espaço reservar.
• Use a aba Network do Chrome DevTools filtrada por origens de terceiros para identificar quais scripts estão contribuindo para deslocamentos de layout.

Lazy loading e placeholders

O lazy loading adia o carregamento de imagens até que estejam próximas do viewport, economizando largura de banda. Mas se nenhum placeholder for definido, o container da imagem colapsa para zero de altura e depois salta ao abrir quando a imagem carrega.

Sempre garanta que elementos com lazy loading tenham dimensões explícitas ou aspect-ratio definido via CSS, para que o navegador reserve o espaço correto antes mesmo de a imagem carregar. Isso se aplica tanto ao loading="lazy" nativo quanto a lazy loaders baseados em JavaScript.

CLS — Perguntas frequentes 2026

O FID ainda é um sinal de ranking em 2026?

Não. O Google aposentou oficialmente o FID (First Input Delay) como Core Web Vital em março de 2024 e o substituiu pelo INP (Interaction to Next Paint). O trio CWV atual é LCP, INP e CLS. Atualize qualquer documentação interna ou ferramenta que ainda faça referência ao FID.

Qual é uma boa pontuação CLS para alcançar?

Os limites do Google: abaixo de 0,1 é “bom”, 0,1–0,25 é “precisa de melhorias”, acima de 0,25 é “ruim”. Mire abaixo de 0,1. A pontuação é medida no 75º percentil dos carregamentos de página nos dados de campo do CrUX.

O CLS afeta o ranking?

Sim, mas é um sinal entre muitos. Os Core Web Vitals são um fator de ranking de experiência de página desde meados de 2021. Um CLS ruim não vai destruir uma página forte, mas pode ser um desempate e prejudicará diretamente as métricas de engajamento do usuário (taxa de rejeição, profundidade de sessão) por seus próprios méritos.

Minha pontuação no PSI mostra bom CLS, mas o Search Console sinaliza a página como ruim — qual está certo?

Confie no Search Console (dados de campo) em vez dos dados de laboratório do PSI quando houver conflito. Os testes de laboratório do PSI simulam apenas o carregamento inicial do viewport; ele perde o CLS acionado pela rolagem do usuário, trocas de fonte em conexões mais lentas ou anúncios carregados após interação. Os dados de campo CrUX no Search Console refletem usuários reais em condições reais.

Leituras relacionadas:

• Como corrigir problemas de LCP no Search Console
• Como otimizar a velocidade do seu site
• Auditoria de SEO técnico

A versão resumida

Se você está lendo isso porque o fluxo de trabalho descrito está consumindo a sua semana, é exatamente esse tipo de loop para o qual eu construo agentes de IA. Duas vagas de desenvolvimento abertas por vez.

Atualizado para maio de 2026

A história do Google em 2026 é de AI Overviews em todo lugar: o experimento SGE de 2023 se tornou um recurso padrão em maio de 2024 e agora aparece em aproximadamente ~60% das consultas informativas dos EUA. Para operadores de SEO e anúncios:

• O CTR orgânico em consultas com AI Overviews caiu 15–30% em média, conforme estudos publicados de Ahrefs, Authoritas e similares (dados de 2024–25).
• Google Ads renomeou várias funcionalidades do PMax como AI-powered Search; a interface de gerenciamento de campanhas agora sugere estratégias de lance com IA por padrão.
• O Search Console adicionou um filtro de “impressões de AI Overview” no final de 2025 — se algum post aqui referencia relatórios do GSC, o manual precisa ser atualizado.
• A receita de anúncios do Google ultrapassou ~US$ 265 bilhões em 2024; o Search ainda representa ~57% da receita total do Alphabet.

A resposta para “como o Google ganha dinheiro” em 2026: ainda são os anúncios do Search (dominantes), mas anúncios do YouTube, Cloud e assinaturas (YouTube Premium + Google One) são linhas materiais agora.