--- title: "CLS no WordPress: como acabar com os layout shifts" id: "522" type: "post" slug: "cls-no-wordpress" published_at: "2026-10-06T15:19:35+00:00" modified_at: "2026-10-06T20:23:42+00:00" url: "https://danielpazwp.com/pt/cls-no-wordpress/" markdown_url: "https://danielpazwp.com/pt/cls-no-wordpress.md" excerpt: "As fontes comuns de layout shift em sites WordPress, de imagens sem dimensões a troca de fontes e banners, e como encontrar e corrigir cada uma delas." taxonomy_category: - "Performance" --- [Performance](https://danielpazwp.com/pt/category/performance-pt/) 7 min de leitura # CLS no WordPress: como acabar com os layout shifts As fontes comuns de layout shift em sites WordPress, de imagens sem dimensões a troca de fontes e banners, e como encontrar e corrigir cada uma delas. Publicado **06/10/2026**7 min de leitura [Escrito porDaniel Paz](https://danielpazwp.com/pt/author/daniel-paz/) Para reduzir o CLS no WordPress, reserve espaço para tudo antes de carregar (imagens, embeds, espaços de anúncio, banners) e impeça que web fonts e CSS atrasado refaçam o fluxo da página. O CLS (Cumulative Layout Shift) dá nota para o movimento inesperado do conteúdo visível e considera a maior rajada de deslocamentos durante a visita. O Google considera bom um valor de até 0,1 no percentil 75, e ruim acima de 0,25. No WordPress as fontes de sempre são imagens sem `width` e `height` nos templates do tema, troca de fontes, barras de cookies e de promoção inseridas acima do header, anúncios e embeds, e plugins de otimização que atrasam ou removem CSS. O CLS é o Core Web Vital que mais irrita as pessoas. Você vai tocar num link, a página se mexe e você acaba tocando num anúncio. Também é o que tem as correções mais mecânicas. Quando você sabe qual elemento se move, a correção costuma ser umas poucas linhas de HTML ou CSS. Para as outras duas métricas e a ordem geral de correção, veja [Core Web Vitals no WordPress: o guia completo](https://danielpazwp.com/pt/core-web-vitals-no-wordpress/) . ## Como o CLS é calculado? Cada layout shift recebe uma nota a partir de dois números: quanto da viewport os elementos que se movem afetam (impact fraction) e quanto eles se deslocam em relação à viewport (distance fraction). Os deslocamentos são agrupados em session windows. Uma janela termina depois de um segundo sem deslocamentos, ou depois de cinco segundos no total. O CLS é a nota da pior janela, não a soma da visita inteira. Dois detalhes explicam a maior parte da confusão sobre o CLS: - Deslocamentos até 500 milissegundos depois de uma ação do usuário (clique, toque ou tecla) ficam de fora. Abrir um accordion quando o usuário toca nele não tem problema. Scroll não conta como ação para essa regra. - No campo, o CLS é medido durante a visita inteira, mas o Lighthouse só observa o carregamento. Deslocamentos causados por conteúdo com lazy load, anúncios que carregam durante o scroll ou headers sticky que mudam de altura aparecem no CrUX e não no seu teste de laboratório. Esse segundo ponto é o motivo de eu nunca encerrar um problema de CLS só com base no Lighthouse. Falo mais sobre a diferença em [Core Web Vitals: dados de campo vs laboratório](https://danielpazwp.com/pt/core-web-vitals-dados-de-campo-vs-laboratorio/) . ## O que causa layout shifts no WordPress? | Causa | De onde vem | Correção | | --- | --- | --- | | Imagens sem dimensões | Templates do tema, widgets do builder, loops customizados | Imprima width e height, ou defina aspect-ratio no CSS | | Troca de web font | Fontes com métricas diferentes da fonte de fallback | Metric overrides no fallback, preload da fonte principal, avalie font-display: optional | | Banners inseridos no topo | Consentimento de cookies, barras de promoção, plugins de notificação | Coloque por cima do conteúdo com posicionamento fixo, ou já reserve o espaço no HTML do servidor | | Anúncios sem espaço reservado | Scripts de anúncio que injetam criativos de tamanho variável | min-height fixo por espaço, no tamanho do criativo mais comum | | Embeds | YouTube, posts de redes sociais, mapas, iframes | Wrappers de embed responsivos com proporção definida | | CSS atrasado ou removido | “Remover CSS não utilizado”, CSS atrasado, folhas de estilo assíncronas | Teste em cada template e mantenha no caminho crítico os estilos da primeira tela | | Sliders e carrosséis | Altura definida só depois que o script roda | Altura fixa ou proporção definida antes da inicialização | | Animações em propriedades de layout | Animar top, left, height ou margin | Anime transform e opacity no lugar | O WordPress resolve parte do problema das imagens por você. O core adiciona `width` e `height` nas imagens do conteúdo dos posts, e o `wp_get_attachment_image()` também imprime esses atributos. Os deslocamentos que encontro nas auditorias normalmente vêm de código que passa por fora dos dois: templates do tema que montam tags `img` na mão, widgets de builder e plugins que injetam imagens com JavaScript. No caso dos embeds, temas de blocos e temas clássicos que declaram `add_theme_support( 'responsive-embeds' )` recebem estilos do core que mantêm a proporção dos vídeos incorporados. Sem esse suporte, um embed pode carregar num tamanho e depois mudar. ## Como encontrar o elemento que se desloca? - No PageSpeed Insights, a auditoria de grandes layout shifts do Lighthouse lista os elementos que se moveram durante o carregamento de laboratório. - No painel Performance do Chrome DevTools, os layout shifts gravados aparecem numa trilha própria, e selecionar um deles destaca o elemento. - O build de attribution da biblioteca web-vitals informa o elemento por trás do maior deslocamento nas visitas reais, incluindo os que acontecem depois do carregamento. A attribution de campo é o que mais importa no CLS, porque muitos deslocamentos só acontecem depois que o usuário rola a página. Se o Lighthouse mostra CLS 0 e o Search Console diz que suas páginas mobile estão ruins, o deslocamento acontece mais adiante na visita. ## Como corrigir o CLS causado por fontes no WordPress? Quando uma web font substitui a fonte de fallback, o texto refaz o fluxo se as duas fontes tiverem larguras ou alturas de linha diferentes. Cada quebra de linha pode mudar, e tudo o que está abaixo muda junto. - Hospede a fonte no seu servidor em vez de carregar de um arquivo CSS de terceiros. Temas de blocos podem registrar fontes no `theme.json` em `fontFace`, incluindo o valor de `fontDisplay`, e desde o WordPress 6.5 a Font Library instala as fontes no seu próprio servidor. - Faça preload dos um ou dois arquivos de fonte usados acima da dobra. - Ajuste a fonte de fallback com `size-adjust`, `ascent-override` e `descent-override` numa regra `@font-face`, para ela ocupar o mesmo espaço que a web font. - Use `font-display: optional` quando a marca aceitar o fallback numa primeira visita lenta. Isso evita a troca tardia por completo. O carregamento de fontes também afeta o LCP quando o elemento LCP é um título, então esse trabalho costuma ajudar as duas métricas. Para o lado do carregamento, veja [como melhorar o LCP no WordPress](https://danielpazwp.com/pt/lcp-no-wordpress/) . ## Plugins de cache e otimização podem causar CLS? Podem, e com frequência. Recursos que removem CSS não utilizado, atrasam o CSS até a interação ou carregam folhas de estilo de forma assíncrona podem renderizar a página antes de os estilos chegarem. O navegador pinta o conteúdo sem estilo, os estilos chegam e tudo pula. Um CSS crítico gerado que deixa algum componente de fora faz a mesma coisa. Teste esses recursos em todos os tipos de template, num celular de verdade, com cache frio. Se um template quebrar, exclua os estilos dele da otimização em vez de desligar o recurso no site todo. Os mesmos plugins também podem piorar a responsividade quando atrasam scripts, assunto que trato em [como corrigir o INP no WordPress](https://danielpazwp.com/pt/inp-no-wordpress/) . ## Por que headers sticky e contadores de carrinho deslocam a página? Um header que passa de estático para fixo quando o visitante rola a página sai do fluxo do documento, e o conteúdo de baixo sobe na altura do header. Deixe o header sticky desde o início com `position: sticky`, ou mantenha no lugar dele um placeholder da mesma altura. Elementos pequenos também deslocam. Um contador de carrinho no header ou uma saudação que o JavaScript preenche depois do carregamento pode mudar a largura de tudo o que está ao lado. Dê uma largura fixa a esses elementos, ou renderize o conteúdo final deles no HTML quando o cache de página permitir. ## O back/forward cache ajuda no CLS? Quando o visitante volta ou avança, o Chrome pode restaurar a página na hora a partir do back/forward cache (bfcache), sem um novo carregamento e, portanto, sem novos deslocamentos de carregamento. Páginas que enviam `Cache-Control: no-store` ou usam handlers do evento `unload` podem perder essa elegibilidade. O DevTools tem um teste de back/forward cache no painel Application que diz se a página se qualifica e, se não, por quê. ## Como confirmar uma correção de CLS? Reproduza o deslocamento no DevTools, aplique a correção e confirme que ele sumiu da trilha de layout shifts. Depois acompanhe os dados de usuários reais daquele template, incluindo o comportamento no scroll. O CrUX precisa de 28 dias para refletir totalmente a mudança no PageSpeed Insights e no Search Console. ## Ainda vê a página se mexendo? Se o seu CLS reprova no campo e você não consegue reproduzir, o deslocamento provavelmente acontece depois do carregamento, num componente que ninguém testa. Eu encontro esse deslocamento nos dados de campo e rastreio até o tema, plugin ou script que o causa. Saiba mais sobre [minhas auditorias de Core Web Vitals para WordPress](https://danielpazwp.com/pt/especialista-core-web-vitals/) . [Trabalhe com o Daniel](https://danielpazwp.com/pt/#book) [Mais em Performance](https://danielpazwp.com/pt/category/performance-pt/) [Sobre o autorPágina do autor](https://danielpazwp.com/pt/author/daniel-paz/) ## Artigos relacionados [Todos os artigos](https://danielpazwp.com/pt/artigos/) [Performance out 2026Page cache vs object cache vs edge cache: qual você precisa](https://danielpazwp.com/pt/page-cache-object-cache-edge-cache-qual-voce-precisa/) [Performance out 2026Core Web Vitals: dados de campo vs laboratório](https://danielpazwp.com/pt/core-web-vitals-dados-de-campo-vs-laboratorio/) [Performance out 2026WordPress lento: os motivos estruturais e a ordem para corrigir](https://danielpazwp.com/pt/por-que-seu-wordpress-e-lento-motivos-estruturais/)