--- title: "Core Web Vitals no Elementor: como corrigir LCP, INP e CLS" id: "578" type: "post" slug: "core-web-vitals-elementor" published_at: "2026-10-06T20:00:49+00:00" modified_at: "2026-10-06T20:00:49+00:00" url: "https://danielpazwp.com/pt/core-web-vitals-elementor/" markdown_url: "https://danielpazwp.com/pt/core-web-vitals-elementor.md" excerpt: "Por que sites em Elementor reprovam no Core Web Vitals, quais configurações de performance importam e como corrigir topo, DOM, animações e fontes." taxonomy_category: - "Performance" --- [Performance](https://danielpazwp.com/pt/category/performance-pt/) 7 min de leitura # Core Web Vitals no Elementor: como corrigir LCP, INP e CLS Por que sites em Elementor reprovam no Core Web Vitals, quais configurações de performance importam e como corrigir topo, DOM, animações e fontes. Publicado **06/10/2026**7 min de leitura [Escrito porDaniel Paz](https://danielpazwp.com/pt/author/daniel-paz/) Site em Elementor consegue passar no Core Web Vitals, mas o jeito como as páginas são montadas facilita reprovar. As causas comuns são DOM profundo de seções e colunas aninhadas, imagem do topo colocada como fundo em CSS ou dentro de slider, animação de entrada no elemento LCP, CSS e JavaScript de widgets carregados além do necessário, Google Fonts e bibliotecas de ícones, e popups ou cabeçalhos fixos que mexem no layout. Para corrigir o Core Web Vitals no Elementor, ative os recursos de performance do Elementor, refaça os templates mais pesados com contêineres Flexbox, transforme o topo numa imagem de verdade que carrega primeiro e corte o que roda no celular. Confirme no dado de campo, no p75. O Elementor não é o único motivo de um site lento, e quase nunca é a primeira coisa que eu tiraria. Mas é onde mais encontro trabalho evitável nas auditorias de sites feitos com construtor. Para saber como as três métricas são medidas e quais são os limites, veja o [guia completo de Core Web Vitals no WordPress](https://danielpazwp.com/pt/core-web-vitals-no-wordpress/) . ## Por que sites em Elementor reprovam no Core Web Vitals? Um construtor de páginas transforma decisões visuais em marcação. Cada seção, coluna, contêiner e widget vira um ou mais elementos de embrulho, e cada widget pode trazer CSS e script próprios. Quem monta a página vê um layout limpo no editor e nunca vê o DOM que ele gera. A outra causa é de organização. Na maioria dos sites em Elementor que audito, muita gente montou templates ao longo de vários anos, cada pessoa com uma ideia diferente de como fazer um banner ou uma tabela de preços. Então o problema raramente é uma configuração. São alguns templates pesados que concentram a maior parte do tráfego. ## Quais configurações do Elementor importam para performance? O Elementor agrupa as opções de performance nas configurações, na aba Recursos e, nas versões recentes, numa aba Performance. Nomes e padrões mudam entre versões, e alguns já vêm ligados em instalações novas, então confira na sua. Estas são as que procuro: - DOM otimizado e o contêiner Flexbox, que reduzem a quantidade de elementos de embrulho. - Carregamento de assets melhorado, que carrega os scripts de widget só nas páginas que usam aquele widget. - Carregamento de CSS melhorado, que carrega o CSS por widget em vez de um arquivo grande. - Ícones de fonte inline, que desenham os ícones como SVG inline em vez de baixar arquivos inteiros de fonte de ícones. - Lazy load de imagens de fundo, útil abaixo da dobra e prejudicial se pegar o topo. - Carregar Google Fonts localmente, o que elimina a conexão com um servidor de fontes de terceiros. - Método de impressão do CSS. Arquivo externo pode ficar no cache do navegador entre páginas. Incorporação interna evita requisições extras, mas repete o CSS em toda resposta HTML. - Cache de elementos, nas versões que têm, que guarda no servidor o resultado renderizado dos widgets. Ative primeiro em homologação. Alguns desses recursos mudam a marcação, e CSS personalizado escrito para os embrulhos antigos pode quebrar. ## Como corrigir o LCP em páginas Elementor? Na maioria das páginas Elementor, o elemento LCP é o topo: uma imagem de fundo, um widget de Imagem ou um título grande. Estes são os padrões que deixam ele lento. - A imagem do topo é fundo em CSS. O navegador só descobre uma imagem de fundo depois de ter o CSS e saber que o elemento precisa dela, o que acontece mais tarde do que com um `img` no HTML. Use o widget de Imagem no topo sempre que der. Se o design exige fundo, faça preload dessa imagem e garanta que o lazy load de fundos não pegue ela. - O topo é um slider. O primeiro slide muitas vezes espera o script do carrossel iniciar para aparecer no tamanho certo. Um topo estático, ou um slider cujo primeiro slide renderiza sem JavaScript, é mais rápido. - O topo tem animação de entrada. Os efeitos de movimento começam com o elemento escondido e revelam por JavaScript, então o LCP só é registrado quando a animação mostra o elemento. Tire animação de entrada de tudo que está acima da dobra. - Versões de celular e desktop da mesma seção. A visibilidade responsiva esconde elementos com CSS. As duas versões continuam no HTML e no DOM, e uma imagem sem lazy load na cópia escondida ainda pode ser baixada. - CSS que bloqueia a renderização vindo do tema, do kit do Elementor, de widgets globais e de pacotes de addons, tudo carregando antes de qualquer pintura. A decomposição do LCP em quatro partes, em [LCP no WordPress: causas e correções](https://danielpazwp.com/pt/lcp-no-wordpress/) , ajuda a ver qual desses é o seu gargalo. ## Como corrigir o INP em sites Elementor? Problema de INP em site Elementor quase sempre vem de dois lugares: DOM muito grande e scripts que rodam na interação. DOM grande deixa todo recálculo de estilo e de layout mais caro, então até um clique simples vira tarefa longa. Layouts antigos de seção e coluna aninham mais fundo do que o mesmo design feito com contêineres Flexbox. Mega menus, abas aninhadas, acordeões com conteúdo pesado e Loop Grids com muitos itens vão somando. Esconder um widget no celular não tira ele do DOM. Depois vêm os scripts: popups com vários gatilhos, validação de formulário, efeitos fixos que rodam na rolagem, pacotes de addons que carregam a biblioteca inteira em toda página e as tags de terceiros que todo site de marketing tem. Refazer o template mais pesado com contêineres e menos widgets costuma ajudar mais do que qualquer configuração isolada. O método geral está em [INP no WordPress: como corrigir interações lentas](https://danielpazwp.com/pt/inp-no-wordpress/) . ## De onde vem o CLS em sites Elementor? - Cabeçalhos fixos que mudam de altura ou passam de estático para fixo. Role devagar e veja se o conteúdo pula quando o cabeçalho gruda. - Fontes web que trocam tarde, principalmente quando várias famílias e pesos do Google Fonts carregam. - Barras de aviso e popups que empurram o conteúdo para baixo em vez de ficar por cima. - Carrosséis e galerias que mudam de tamanho depois que o script roda. - Imagens em widgets de HTML ou código personalizado sem largura e altura. Reserve espaço para tudo que aparece depois da primeira pintura e limite as fontes aos pesos que você usa de fato. Mais correções em [CLS no WordPress: como evitar deslocamentos de layout](https://danielpazwp.com/pt/cls-no-wordpress/) . ## Referência rápida | Problema | Métrica afetada | O que mudar | | --- | --- | --- | | Topo como fundo em CSS | LCP | Usar widget de Imagem, ou fazer preload e tirar do lazy load | | Slider no topo | LCP e CLS | Topo estático, ou primeiro slide que renderiza sem JavaScript | | Animação de entrada acima da dobra | LCP | Tirar o efeito de movimento do topo | | Seções e colunas muito aninhadas | INP | Refazer com contêineres Flexbox | | Seções duplicadas para celular e desktop | LCP e INP | Uma seção responsiva em vez de duas cópias escondidas | | Muitas famílias e pesos de fonte | LCP e CLS | Menos pesos, carregados localmente | | Addons carregados no site inteiro | LCP e INP | Carregar só onde usa, remover addons parados | | Cabeçalho fixo que muda de tamanho | CLS | Altura fixa, ou um espaço reservado da mesma altura | ## Precisa sair do Elementor? Normalmente não como primeiro passo. Começo refazendo os dois ou três templates que concentram mais tráfego, ligando os recursos de performance e limpando os addons. Isso resolve a maior parte das reprovações que vejo. Se o site continua reprovando depois disso, ou se já vem um redesign, vale comparar com um tema de blocos, o que faço em [Elementor vs Gutenberg em performance](https://danielpazwp.com/pt/elementor-vs-gutenberg-performance-pt/) . Para velocidade do Elementor além das três métricas, veja [como acelerar o Elementor](https://danielpazwp.com/pt/como-acelerar-elementor/) , e para o que um plugin de cache ou otimização acrescenta, veja [os melhores plugins para Core Web Vitals](https://danielpazwp.com/pt/plugins-core-web-vitals/) . Se você quer os seus templates Elementor rastreados e ordenados pelo que corrigir primeiro, a minha [auditoria de performance WordPress](https://danielpazwp.com/pt/auditoria-performance-wordpress/) faz exatamente isso. [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/)