# CLS no WordPress: Como zerar o layout shift em 5 passos O CLS mede o quanto o layout do seu site pula durante o carregamento, e o alvo é ficar em 0,1 ou menos. Segundo o web.dev (2024), um CLS bom fica em 0,1 ou menos no percentil 75 dos acessos. As três causas dominantes são imagens sem dimensão, fontes externas e blocos injetados por JavaScript. Resolver essas três zera quase todo o índice. O CLS, ou Cumulative Layout Shift, é a métrica dos Core Web Vitals que pontua a estabilidade visual da página enquanto ela carrega. Quando uma imagem entra sem espaço reservado, o texto abaixo dela é empurrado, e esse pulo conta pontos contra você. No WordPress, o problema quase sempre vem de imagens sem largura declarada, fontes carregadas de fora e banners injetados depois do load. Nos tickets de performance que chegam na FULL, o CLS é o vital que mais confunde, porque ele passa no teste de laboratório e falha no usuário real. Este guia mostra a origem de cada shift e como derrubar o CLS abaixo de 0,1 sem reescrever o tema. Para o contexto completo das três métricas, veja o guia de Core Web Vitals no WordPress e a categoria de conteúdos de performance WordPress. --- ## Primeiros passos: O que o CLS mede e qual é o alvo O CLS soma cada deslocamento inesperado de elemento visível durante o carregamento, e a meta oficial é ficar em 0,1 ou menos. Segundo o web.dev (2024), que documenta os Core Web Vitals, um CLS bom fica em 0,1 ou menos no percentil 75 dos acessos; entre 0,1 e 0,25 é "precisa melhorar" e acima de 0,25 é ruim. A tabela abaixo resume o diagnóstico que aplicamos antes de tocar em qualquer plugin, cruzando faixa de índice, sintoma visível e a primeira ação que costuma resolver. Use-a como mapa rápido: identifique sua faixa no PageSpeed Insights e siga a coluna de ação. Essa leitura inicial economiza tempo, porque cada faixa tem uma causa raiz diferente e atacar a errada não move o número.
CLS no WordPress: faixa do indice, sintoma e primeira acao
Faixa de CLS Sintoma visivel Primeira acao corretiva
0 a 0,1 (bom) Pagina estavel, sem pulos perceptiveis. Monitorar no CrUX; manter atributos de dimensao.
0,1 a 0,25 (medio) Texto reposiciona quando imagem ou fonte carrega. Declarar width e height; usar font-display swap.
Acima de 0,25 (ruim) Conteudo salta com banner ou anuncio tardio. Reservar espaco para blocos injetados por JavaScript.
--- ## Por que o CLS passa no teste e falha no usuário real A razão número um para essa divergência é o momento da medição: o Lighthouse roda em uma janela fixa de poucos segundos, enquanto o CrUX coleta o índice de campo durante toda a sessão real do usuário, capturando shifts tardios que o laboratório nunca chega a registrar antes de encerrar. Nos tickets de suporte da FULL, em mais de metade dos casos de CLS "fantasma" o culpado é o banner de consentimento de cookies injetado por JavaScript segundos após o load. O Lighthouse encerra a medição antes de o banner aparecer, então marca o índice abaixo de 0,1; o usuário real rola a página, o banner entra no topo sem espaço reservado e empurra tudo, gerando um deslocamento de campo acima de 0,2. A solução é reservar altura fixa para o banner via CSS antes de ele renderizar. Sempre meça o CLS no relatório de campo do PageSpeed Insights, porque o número que conta para o ranqueamento é o de campo. --- ## As 3 causas mais comuns de CLS no WordPress Três fontes respondem por quase todo o CLS que vemos em sites WordPress: imagens sem dimensão, fontes externas e injeção tardia de blocos. A mais frequente é a imagem sem os atributos width e height, que faz o navegador renderizar o texto e depois empurrar o bloco abaixo quando a imagem chega, gerando um índice que tende a passar de 0,25. A segunda causa é a fonte: uma Google Fonts carregada via @import sem font-display swap em uma conexão 4G produz flash de texto invisível seguido de reflow tipográfico, e o reposicionamento das linhas conta pontos no índice. A terceira é qualquer elemento injetado por JavaScript depois do render, como banner de cookies, barra de promoção ou anúncio, que entra sem espaço reservado. Identificar qual das três domina seu site é o passo que define a correção certa. --- ## Passo a passo: Como reduzir o CLS no WordPress Reduzir o CLS no WordPress segue cinco passos em ordem de impacto, e os três primeiros costumam derrubar o índice de 0,3 para abaixo de 0,1. A sequência ataca primeiro as causas de maior peso, imagem e fonte, e depois os shifts tardios injetados por JavaScript. Cada passo tem um check de validação no PageSpeed Insights, então rode o teste de campo entre um passo e outro para medir o ganho real antes de seguir. Ferramentas como WP Rocket, Perfmatters e o próprio editor do tema cobrem todas as etapas sem edição manual de código. ### Passo 1: Declare width e height em todas as imagens Garanta que cada imagem traga os atributos width e height no HTML, porque eles dizem ao navegador quanto espaço reservar antes do download. O WordPress 5.5+ injeta esses atributos automaticamente em imagens do editor de blocos, mas temas antigos e construtores como Elementor às vezes os removem. Reative a dimensão pelo plugin de otimização e confirme no código-fonte. Esse único ajuste resolve a maior fatia do CLS em blogs com muitas imagens. Veja o tutorial de como aplicar lazy load em imagens e vídeos para combinar carregamento adiado com dimensão reservada. ### Passo 2: Hospede a fonte localmente com font-display swap Mova a tipografia de Google Fonts externa para hospedagem local e aplique font-display swap, eliminando a requisição de fora que atrasa o render do texto. A fonte externa cria duas falhas: latência da requisição e reflow quando a fonte real substitui a de fallback. Perfmatters e WP Rocket têm a opção "hospedar Google Fonts localmente" em um clique. Com swap ativo, o texto aparece imediatamente na fonte de sistema e troca sem pulo perceptível, mantendo o CLS estável. ### Passo 3: Reserve espaço para blocos injetados por JavaScript Defina uma altura mínima via CSS para banner de cookies, barra de aviso e qualquer bloco que o JavaScript insere depois do load. Sem esse espaço reservado, o elemento entra e empurra todo o conteúdo abaixo, criando o layout shift tardio que o Lighthouse não detecta. Use min-height no container do banner ou posicione-o como overlay fixo, fora do fluxo do documento. Esse passo resolve o CLS de campo que parecia invisível no teste de laboratório. ### Passo 4: Padronize a dimensão de embeds e anúncios Aplique aspect-ratio fixo a vídeos do YouTube, mapas e blocos de anúncio, que entram com altura variável e deslocam o conteúdo. Um embed de vídeo sem proporção declarada renderiza primeiro como caixa estreita e depois expande, gerando shift. O CSS aspect-ratio 16 / 9 no wrapper do embed reserva o espaço correto desde o início. Plugins de cache costumam ter um módulo de "embeds responsivos" que faz isso automaticamente. ### Passo 5: Valide o CLS no campo e monitore a regressão Confirme o ganho no relatório de campo do PageSpeed Insights e ative monitoramento contínuo, porque um plugin novo pode reintroduzir CLS a qualquer deploy. O CrUX leva até 28 dias para refletir a correção, então a queda do índice não é instantânea no relatório de campo. Rode o teste de laboratório para o resultado imediato e acompanhe o campo ao longo do mês. Para um diagnóstico mais amplo do site, use as ferramentas de teste de desempenho WordPress que reunimos por categoria. --- ## Quanto o CLS pesa nos Core Web Vitals e no ranqueamento O CLS é um dos três Core Web Vitals que o Google usa como sinal de experiência da página, ao lado do LCP e do INP. De acordo com o HTTP Archive (2024), que mede Core Web Vitals por CMS em milhões de URLs, o índice aprovado em sites WordPress subiu de forma consistente entre 2023 e 2024. Esse ganho veio conforme os temas adotaram dimensão automática de imagem no WordPress 5.5 e versões seguintes. Mesmo assim, a estabilidade visual continua sendo o vital que mais reprova em construtores visuais. Tende a ser, na maioria dos sites Elementor que auditamos no suporte, o último dos três a passar, porque o construtor adiciona widgets dinâmicos pesados acima da dobra. Reduzir o TTFB e o tempo de resposta do servidor ajuda o conjunto da nota, mas não corrige o layout shift sozinho quando a causa é estrutural do tema. --- ## Acelere o WordPress com o cache e a otimização do bundle FULL Resolver CLS, TTFB e cache plugin a plugin custa caro e dá manutenção. O plano PRO da FULL sai por R$849 e inclui WP Rocket e Perfmatters já licenciados e gerenciados, o que dá cerca de R$85 por site quando você distribui o bundle pelos 10 sites do plano, em qualquer hospedagem. A gente não hospeda seu site: a otimização premium roda no WordPress que você já tem instalado, seja qual for o servidor ou o provedor de hospedagem. No suporte da FULL, a maior parte dos casos de layout shift some quando o cache e o lazy-load entram configurados de fábrica, sem nenhum ajuste manual. Conheça os planos da FULL e compare o custo por site com a soma das licenças avulsas. Para aprofundar, o guia Acelere o WordPress reúne os tutoriais de performance em sequência. --- ## Quando o CLS não é o seu maior problema Nem sempre a estabilidade visual é o gargalo do site: em sites com TTFB acima de 800 ms, o ganho de corrigir o layout shift é marginal perto de resolver o tempo de resposta do servidor, que sozinho costuma segurar o LCP inteiro acima da meta. A gente vê no suporte da FULL casos em que o dono otimiza o índice por dias enquanto o LCP estoura em 5 segundos por hospedagem lenta. Priorize pela métrica que mais reprova no PageSpeed Insights. Se o LCP e o INP estão verdes e só a estabilidade reprova, este guia resolve; se os três reprovam, comece pelo servidor e pelo cache. Para o caso específico de tempo de resposta, veja como reduzir o TTFB no WordPress, e para sites pesados de construtor, o diagnóstico de Elementor lento aponta os widgets que mais custam.

Legenda: o relatório de campo separa o CLS de laboratório do CLS real do usuário, e é o de campo que conta para o ranqueamento.

Perguntas frequentes sobre CLS no WordPress

Por que o CLS do meu site muda entre o teste e o uso real?

Porque o laboratório do Lighthouse mede uma janela fixa de carregamento, enquanto o CrUX coleta o CLS de campo durante toda a sessão do usuário. Elementos que entram tarde, como banner de cookies injetado por JavaScript, não aparecem no teste de laboratório mas deslocam o conteúdo do usuário real. O número que vale para o ranqueamento é sempre o de campo, no percentil 75.

É possível zerar o CLS sem mexer no código do tema?

Sim, na maioria dos casos. Plugins como WP Rocket e Perfmatters reativam os atributos width e height nas imagens, hospedam Google Fonts localmente com font-display swap e aplicam aspect-ratio em embeds, sem edição de código. O único ajuste que às vezes exige CSS é reservar altura para o banner de cookies, e mesmo esse muitos plugins de consentimento já oferecem como opção pronta.

Qual valor de CLS o Google considera bom no WordPress?

Um CLS bom fica em 0,1 ou menos, medido no percentil 75 dos acessos, segundo a documentação do web.dev. Entre 0,1 e 0,25 a página fica na faixa "precisa melhorar" e acima de 0,25 é classificada como ruim. O alvo vale igual para mobile e desktop, avaliados de forma separada pelo Google.

Quanto o CLS pesa na nota dos Core Web Vitals?

O CLS é um dos três Core Web Vitals oficiais, junto com LCP e INP, e os três precisam estar verdes para a página passar na avaliação de experiência. Não há um peso percentual público entre eles: reprovar em qualquer um já tira a página do status "bom". Na prática, essa métrica costuma ser a última a passar em sites de construtor visual.

O que causa CLS em sites feitos com Elementor?

No Elementor, o layout shift vem principalmente de widgets dinâmicos acima da dobra que carregam com altura variável e de imagens cujo atributo de dimensão o construtor remove na renderização. Sliders, carrosséis e blocos de post dinâmico entram depois do primeiro paint e deslocam o conteúdo. Declarar dimensão fixa e reservar espaço para esses widgets resolve a maior parte do índice.

--- ## Próximos passos para estabilizar o layout do seu site Comece medindo o CLS de campo no PageSpeed Insights, identifique se a causa é imagem, fonte ou bloco injetado, e ataque na ordem dos cinco passos: dimensão de imagem, fonte local, espaço para banner, embeds e validação. Essa métrica é o Core Web Vital mais sensível a plugin novo, então monitore o índice depois de cada deploy. Na maioria dos sites WordPress, declarar width e height e hospedar a fonte localmente já derruba o número de 0,3 para abaixo de 0,1. Para continuar aprendendo, o FULL Academy reúne tutoriais, guias e reviews de performance em um só lugar.