| Gargalo | Como aparece | Recurso que ataca |
|---|---|---|
| DOM grande | HTML com milhares de divs aninhadas | Optimized DOM Output |
| CSS inline | Estilo repetido em cada widget | Improved CSS Loading |
| JavaScript extra | Scripts carregando fora da página | Improved Asset Loading |
| Imagens pesadas | LCP alto na primeira dobra | WebP + lazy loading |
Legenda: os recursos de performance do Elementor ficam concentrados em uma única aba, o que facilita ativar um por vez.
## Por que otimizar Elementor exige ordem e não força bruta Ativar tudo de uma vez é o erro mais comum ao otimizar Elementor. Cada um dos cerca de 6 recursos de performance muda como o HTML é gerado, e dois deles podem deslocar margens em layouts antigos. Por isso a ordem importa: comece pelo de menor risco visual e deixe os que reescrevem o DOM por último. Nos tickets da FULL, boa parte dos casos de "ficou quebrado depois que otimizei" vem de ativar o Optimized DOM Output direto em produção, sem staging. O segundo motivo da ordem é que nem todo gargalo está no builder: se o tema é pesado ou a hospedagem tem TTFB alto, o LCP continua ruim mesmo com todos os recursos ligados. Vale cruzar o diagnóstico com Core Web Vitals no WordPress e entender o LCP no WordPress antes de culpar o Elementor, porque otimizar o builder não conserta uma base lenta. --- ## Passo a passo: Otimizar Elementor em 7 passos Otimizar Elementor sem quebrar nada segue uma sequência clara: do menor risco visual ao maior. Os sete passos abaixo cobrem DOM, CSS, JavaScript, fontes, imagens, cache e validação. Faça um de cada vez e rode o PageSpeed Insights depois de cada ativação, assim você isola qual recurso trouxe ganho e qual mexeu no layout. Em ambiente de testes, o ciclo inteiro leva cerca de 30 a 40 minutos por template. ### Passo 1: Troque por um tema leve como o hello Elementor Comece pela base. Um tema pesado anula qualquer ganho do builder, então troque por um tema enxuto antes de mexer no resto. O Hello Elementor foi feito para isso: entrega quase nenhum CSS próprio e deixa o Elementor cuidar do visual. Em sites que chegam ao suporte da FULL com tema multiuso cheio de recursos, a simples troca já corta peso de CSS. Faça a troca em staging, porque temas trazem estilos globais que podem alterar tipografia e espaçamento. ### Passo 2: Ative improved CSS loading para cortar CSS inline Vá em Elementor > Configurações > Recursos e ative o Improved CSS Loading. Esse recurso carrega o CSS de cada widget em arquivo externo cacheável, em vez de repetir estilo inline no HTML de toda página. O efeito é um HTML menor e CSS reaproveitado entre páginas. Combine com minificar CSS e JavaScript no WordPress para reduzir ainda mais o peso. Teste uma página com muitos widgets, porque é onde a diferença de tamanho do HTML mais aparece. ### Passo 3: Ative improved asset loading para o JavaScript Ainda na aba de recursos, ligue o Improved Asset Loading. Ele faz o Elementor carregar scripts de widgets só nas páginas que usam aquele widget, em vez de em todo o site. Isso reduz JavaScript desnecessário em páginas simples, como a home ou um post de blog. O ganho é maior quanto mais variados forem seus templates. Depois de ativar, navegue pelas páginas principais e confira se sliders, abas e formulários continuam funcionando, já que são os elementos que mais dependem de script. ### Passo 4: Ative optimized DOM output com cuidado Este é o passo de maior risco visual, por isso vem agora. O Optimized DOM Output reduz o número de divs que o Elementor gera por seção, deixando o HTML mais enxuto e rápido de renderizar. Em layouts criados depois da versão 3.6, a transição costuma ser limpa. Em sites antigos com muitas seções aninhadas, ative em staging e valide página por página, porque a remoção de wrappers pode deslocar margens. Otimizar Elementor aqui rende um DOM menor, mas exige conferência visual. ### Passo 5: Carregue ícones e fontes do jeito leve Ative Inline Font Icons para o Elementor injetar os ícones como SVG, evitando baixar a fonte de ícones inteira. Em seguida, ajuste o Font Display para swap, o que mostra o texto com fonte de sistema enquanto a fonte web carrega e evita texto invisível. Esses dois ajustes atacam o CLS e o tempo até o texto aparecer. Se o site usa muitas variações de fonte do Google, hospedar as fontes localmente complementa o ganho e tira uma requisição externa do caminho crítico. ### Passo 6: Trate imagens com WebP e lazy loading Imagem pesada é a causa número um de LCP alto na primeira dobra. Converta as imagens para WebP e garanta o lazy loading nas que ficam abaixo da dobra. Veja o passo a passo em converter imagens para WebP no WordPress. Uma ressalva importante: nunca aplique lazy loading na imagem que é o elemento LCP da página, porque isso atrasa justamente o que o Google mede. Defina a imagem principal como carregamento prioritário e deixe o lazy loading para o resto. ### Passo 7: Adicione cache de página e valide o resultado Por último, coloque uma camada de cache de página por cima de tudo. O cache serve o HTML pronto e é o que entrega o maior salto de TTFB. Configure com atenção ao Elementor PRO: veja como configurar o WP Rocket com Elementor e WooCommerce. Cuidado com o Delay JavaScript agressivo sem exclusão de handles do Elementor: ele tende a impedir que popups e formulários abram, sem erro visível no admin. Rode o PageSpeed Insights uma última vez e compare com o número inicial. --- ## Recursos e ferramentas para otimizar Elementor Otimizar Elementor mistura recursos nativos do builder com 4 ferramentas externas reais, e saber qual faz o quê evita sobreposição. O Perfmatters desliga scripts por página e controla heartbeat, o WP Rocket entrega cache de página e delay de JavaScript, o PageSpeed Insights mede o resultado e o WP-Optimize limpa o banco de dados. O Elementor PRO 3.x já cobre DOM, CSS e carregamento de assets pela própria aba de recursos, então empilhar duas ferramentas que fazem cache ao mesmo tempo só gera conflito. Para o detalhe técnico de cada experimento, consulte a central de ajuda oficial do Elementor, que descreve o comportamento de cada um. A gente vê no suporte da FULL que a maioria dos sites lentos não precisa de mais plugin, e sim de configurar o que já existe. Para comparar abordagens, como otimizar a velocidade do Elementor com plugins específicos detalha as combinações que valem a pena. ## Quanto custa otimizar Elementor com as ferramentas certas A gente vê no suporte da FULL que a conta de comprar Perfmatters, WP Rocket e Elementor PRO separados assusta: somadas, as licenças anuais passam de US$200 por ano por site. Comprar cada uma avulsa também espalha 3 datas de renovação diferentes para você controlar. No bundle da FULL, esses plugins entram juntos no mesmo plano, com licença oficial e atualização automática. O plano PRO da FULL custa R$849 e cobre até 10 sites, o que dá cerca de R$85 por site com Elementor PRO, WP Rocket e Perfmatters já ativados. Para quem gerencia vários sites, ver os planos da FULL costuma sair mais barato que renovar cada licença avulsa, sem falar do trabalho de controlar vencimentos um a um e do risco de um site ficar sem atualização de segurança porque a licença venceu sem ninguém perceber. ---Porque o Elementor injeta CSS e scripts por widget, e por padrão parte desse código carrega em toda página, mesmo nas que não usam aquele widget. Em uma home simples, isso significa baixar JavaScript de slider e de formulário sem necessidade. Ativar o Improved Asset Loading limita os scripts às páginas que realmente usam cada elemento, o que corta peso morto e reduz o tempo de carregamento.
Sim, e é o ponto de partida correto. Os recursos nativos do Elementor PRO 3.x (Improved CSS Loading, Improved Asset Loading, Optimized DOM Output) reduzem DOM, CSS e JavaScript sem nenhum plugin extra. O cache de página entra depois como camada final para melhorar o TTFB. Começar pelo cache antes de enxugar o HTML só mascara o problema: você serve rápido um código que continua pesado por baixo.
Os experimentos do Elementor atuam na origem, mudando como o builder gera HTML, CSS e JavaScript da página. Um plugin como o Perfmatters ou o WP Rocket atua depois, desligando scripts, adiando JavaScript e servindo cache. São camadas complementares, não concorrentes. A regra prática é enxugar primeiro na fonte com os recursos do Elementor e só então adicionar o plugin para tratar o que sobrou, evitando ferramentas que fazem cache duplicado.
Depende do estado inicial, mas a meta é clara: segundo o web.dev, um LCP bom fica em 2,5 s ou menos no percentil 75. Os recursos do Elementor ajudam ao reduzir CSS inline e DOM, o que acelera a renderização. Ainda assim, se o elemento LCP for uma imagem pesada na primeira dobra, o maior ganho vem de converter a imagem para WebP e marcá-la como carregamento prioritário, não dos experimentos do builder.
Comece pelos recursos de menor risco visual: cache de elementos, Inline Font Icons e Font Display. Em seguida ative Improved CSS Loading e Improved Asset Loading, que raramente afetam o design. Deixe o Optimized DOM Output por último, porque ele reescreve a estrutura de divs e pode deslocar margens em layouts antigos. Ative um por vez em staging, rode o PageSpeed Insights e valide as páginas principais antes de subir para produção.