Para acelerar o Elementor, comece pelo servidor e pelo cache de página e só depois reduza o que o Elementor coloca em cada página. Na prática: montar o layout com o Container Flexbox em vez de seções e colunas aninhadas, ligar os recursos de performance que a sua versão oferece (saída de DOM otimizada, carregamento condicional de CSS e JavaScript, ícones inline), carregar as fontes localmente, tirar a imagem principal do lazy load e das animações de entrada e desligar os widgets de add-ons que ninguém usa. O Elementor raramente é lento sozinho. Ele fica lento quando o layout tem cinco níveis de aninhamento e cada add-on carrega seus arquivos em todas as URLs.
Audito muito site em Elementor, e o construtor costuma levar a culpa por problemas que ele só facilitou. Este guia segue a ordem em que eu trabalho. Ele faz parte do guia maior sobre como acelerar o WordPress e, se o seu problema é um relatório de Core Web Vitals reprovado, leia junto Core Web Vitals no Elementor: o que corrigir primeiro.
Por que sites em Elementor ficam lentos?
O Elementor cobra em três lugares. Descobrindo qual deles pesa no seu site, a lista de correções fica curta.
- Profundidade do HTML. Cada seção, coluna, seção interna e invólucro de widget vira um nó no DOM. Layouts antigos feitos com seções e colunas costumam terminar com um DOM enorme, o que deixa cálculo de estilo e layout mais lentos e piora o INP em celular mais simples.
- CSS e JavaScript. O Elementor carrega os arquivos do front-end, um CSS por página, bibliotecas de ícones e fontes. Os pacotes de add-ons trazem os próprios arquivos, muitas vezes em todas as páginas, usando o widget ou não.
- Trabalho de PHP. O Elementor guarda o layout como dados em post meta e renderiza tudo por classes PHP de widget a cada requisição sem cache. Com cache de página na frente, tudo bem. Sem cache, sai caro.
Os dois primeiros aparecem no Lighthouse e nos dados de campo. O terceiro aparece como TTFB alto para usuário logado, nas páginas de carrinho e checkout e em tudo que escapa do cache.
Para acelerar o Elementor, comece pelo servidor e pelo cache de página
Antes de mexer em qualquer configuração do Elementor, eu olho o que acontece numa requisição sem cache. Se o HTML leva mais de um segundo para chegar, nenhum ajuste de CSS vai colocar o LCP abaixo de 2,5 segundos no celular. Confirme que um cache de página atende os visitantes anônimos, que parâmetros de campanha e cookies não furam esse cache, que o PHP está numa versão suportada com OPcache ligado e que existe cache de objetos persistente se o site tem muito usuário logado. O passo a passo dessa parte está no guia de como reduzir o TTFB no WordPress.
Quais configurações do Elementor ajudam de verdade?
O Elementor muda os recursos de performance de lugar entre uma versão e outra. Alguns começam como experimentos em Elementor > Configurações > Recursos (nas versões antigas a tela se chamava Experimentos), outros viram padrão e somem dessa tela, e algumas opções ficam numa aba de Performance ou Avançado. Por isso não cito número de versão. Abra as suas configurações e procure estes nomes (a interface pode estar em inglês ou português, dependendo do idioma do painel):
| Recurso ou configuração | O que muda | O que conferir depois |
|---|---|---|
| Container Flexbox (Flexbox Container) | Troca os invólucros de seção e coluna por um único container flex, e o mesmo layout passa a usar menos nós | Páginas antigas mantêm a estrutura antiga até você converter ou refazer |
| Saída de DOM otimizada (Optimized DOM Output) | Remove alguns invólucros legados do HTML dos widgets | CSS personalizado que mirava esses invólucros |
| Carregamento de assets melhorado (Improved Asset Loading) | Carrega os scripts de um widget só nas páginas que usam aquele widget | Widgets que funcionavam e perderam algum comportamento |
| Carregamento de CSS melhorado (Improved CSS Loading) | Carrega o CSS só dos widgets presentes na página | Estilo de widgets dentro de templates e popups |
| Ícones de fonte inline (Inline Font Icons) | Renderiza os ícones como SVG inline em vez de carregar uma fonte de ícones | Ícones em código próprio que dependem das classes da fonte |
| Lazy load de imagens de fundo (Lazy Load Background Images) | Atrasa as imagens de fundo definidas no Elementor até perto da área visível | Nunca use no fundo do hero se ele for o elemento LCP |
| Cache de elementos (Element Caching) | Guarda a saída renderizada dos elementos, e a requisição sem cache faz menos PHP | Widgets dinâmicos que precisam mostrar conteúdo atual ou por usuário |
| Método de impressão de CSS (CSS Print Method) | Escolhe entre um arquivo CSS externo por página e CSS embutido no HTML | Arquivo externo aproveita melhor o cache entre páginas; embutido economiza uma requisição em visitas de página única |
Depois de mudar qualquer um desses, regenere os arquivos em Elementor > Ferramentas e teste a página em staging. Um CSS gerado desatualizado faz uma mudança correta parecer quebrada, então limpe o cache de página também.
Vale refazer os layouts antigos com containers?
Não tudo de uma vez. Refazer todas as páginas custa caro e quase nunca é necessário. Eu escolho os templates com mais tráfego: em geral a home, os templates de cabeçalho e rodapé, os principais templates de serviço ou produto e o template de post do blog. Cabeçalho e rodapé pesam mais do que parece, porque aparecem em todas as URLs. Converter esses poucos templates para containers costuma tirar mais nós do DOM no site inteiro do que refazer cinquenta páginas com pouca visita.
Aproveite para achatar a estrutura. Container dentro de container dentro de container só para dar espaçamento é o mesmo problema com outro nome.
Como tratar fontes e ícones?
Fonte é um dos ganhos mais fáceis em site Elementor. Por padrão, o Elementor pode carregar do servidor do Google cada família e cada peso usado no kit ou em qualquer widget. Minha ordem:
- Limitar o kit a duas famílias e aos pesos que você usa de fato. Cada peso a mais é mais um arquivo.
- Usar a opção de carregar as Google Fonts localmente, se a sua versão tiver, ou desligar as Google Fonts no Elementor e hospedar os arquivos pelo tema.
- Definir o font-display como swap, que o Elementor oferece como configuração para Google Fonts, para o texto aparecer enquanto a fonte baixa.
- Fazer preload só de um ou dois arquivos de fonte usados acima da dobra.
Nos ícones, o Inline Font Icons tira a maior parte do peso. Se não der para usar, veja se o site ainda carrega o suporte ao Font Awesome 4 para conteúdo antigo e desligue quando nada depender dele. Carregar uma biblioteca inteira de ícones para três ícones de rede social no rodapé é achado frequente nas minhas auditorias.
O que derruba o LCP em páginas Elementor?
O hero concentra a maior parte dos problemas de LCP no Elementor, e eles vêm de três hábitos.
O primeiro é colocar a imagem principal como fundo em CSS. O navegador só descobre essa imagem depois de baixar e interpretar o CSS, então o download começa tarde. Um widget de imagem no HTML é encontrado pelo preload scanner na hora. O segundo é aplicar lazy load no hero. Confira o HTML gerado: se a imagem LCP tem loading=”lazy”, ela espera o layout para começar a baixar. O terceiro são as animações de entrada. O Elementor esconde o elemento animado até o script rodar e revelá-lo, então um título ou imagem animado no hero só aparece depois que o JavaScript executa. Tire animação de entrada de tudo que fica acima da dobra.
O WordPress 6.3 passou a adicionar fetchpriority=”high” na imagem que o core identifica como provável LCP, mas o HTML de construtor nem sempre passa pelo mesmo caminho. Olhe o HTML da sua página em vez de supor. O passo a passo completo está no guia de como melhorar o LCP no WordPress.
Pacotes de add-ons, popups e widgets de terceiros
Quase todo site Elementor que eu audito tem pelo menos um pacote de add-ons instalado por causa de um ou dois widgets. Muitos desses pacotes têm um gerenciador de módulos ou widgets nas configurações. Desligue todos os que você não usa e confira na aba de rede se os arquivos sumiram, porque alguns pacotes continuam carregando um bundle compartilhado.
Popups, sliders, mega menus e widgets de chat são os suspeitos de sempre no INP. Eles registram eventos e rodam JavaScript na interação, e num celular lento é ali que o orçamento de 200 ms vai embora. Se o slider existe só porque alguém pediu anos atrás, tirar resolve mais do que otimizar. Mais sobre isso no guia de como corrigir o INP no WordPress.
Plugins de cache funcionam com o Elementor?
Funcionam, mas as opções agressivas pedem cuidado. Atrasar todo o JavaScript até a interação e remover CSS não usado são os dois recursos que mais quebram menu, abas, sliders e popups do Elementor, porque o CSS desses estados não é usado no primeiro render e os scripts precisam rodar cedo. Ligue um recurso por vez, teste o menu mobile e os popups e crie exceções para o que quebrar. Comparo os principais plugins em melhor plugin de cache para WordPress.
O que medir depois de cada mudança?
Mude uma coisa e meça. Estes são os números que eu anoto antes e depois:
- LCP, INP e CLS dos dados de campo (CrUX ou RUM próprio), lembrando que o CrUX é uma janela móvel de 28 dias e não muda na manhã seguinte
- tamanho do DOM informado pelo Lighthouse nos templates principais
- quantidade e peso dos arquivos CSS e JavaScript na aba de rede, filtrando pelos caminhos do Elementor e dos add-ons
- TTFB numa requisição sem cache e numa com cache
Ferramenta de laboratório serve para checar uma mudança isolada. Dado de campo mostra se o visitante real percebeu. Se a diferença entre os dois não está clara, leia field data vs lab data.
Perguntas frequentes
O Elementor é ruim para performance?
Não, mas ele facilita montar páginas pesadas. Uma página com containers, poucos add-ons, fontes locais e sem animação no hero consegue passar nos Core Web Vitals. Os sites Elementor lentos que eu vejo costumam ser lentos por hábito de montagem e por add-ons, não pelo núcleo do construtor. Se você está escolhendo construtor para um projeto novo, comparo as duas abordagens em Elementor vs Gutenberg em performance.
O Elementor Pro deixa o site mais lento que a versão gratuita?
O Pro acrescenta widgets, o theme builder e os popups. Os widgets que você usa têm custo; os que você não usa não deveriam carregar com o carregamento condicional ativo. Meça as páginas que usam recursos do Pro, e não o plugin como um todo.
Devo desligar as Google Fonts do Elementor?
Se você hospeda as fontes pelo tema, sim. Se não, use o carregamento local e o font-display swap. O objetivo é o mesmo nos dois casos: nenhuma requisição a servidor de fonte de terceiro no caminho crítico.
Se você quer alguém que passe pelos seus templates Elementor e diga qual dessas correções importa para o seu tráfego, é o que eu faço como especialista em Core Web Vitals: encontro o template lento, explico a causa e comprovo a mudança com dados de campo.