Quando alguém me diz que “Elementor é pesado” ou “site feito com Elementor não ranqueia”, eu sei exatamente o que está por trás dessa afirmação: a pessoa viu — ou sofreu — um site profissional Elementor feito da forma errada. O problema nunca foi a ferramenta. Foi a execução. E a diferença entre as duas é o que o cliente sente no carregamento e o que o Google mede nos Core Web Vitals.
O que é um Elementor “genérico” — e por que ele dói na performance
Um Elementor genérico é aquele instalado com o tema padrão do builder, carregado com uma dúzia de plugins auxiliares que o próprio Elementor “sugere”, usando widgets de terceiros de fontes desconhecidas e assets CSS/JS que nunca foram limpos. É o tipo de site que abre o DevTools e mostra 4MB de CSS não utilizado antes mesmo de renderizar a primeira linha de conteúdo visível.
Tecnicamente, o que acontece é simples: o Elementor carrega seu próprio framework de scripts e estilos. Se o tema não foi escolhido pensando em leveza (Hello Elementor ou um tema headless leve), você já está empilhando dois conjuntos de assets. Adicione um plugin de popup, um de formulário com estilos próprios, um de slider que injeta jQuery em toda página — e o resultado é um site com Time to First Byte alto, LCP acima de 4 segundos e um PageSpeed que envergonha.
Como um site profissional Elementor é construído na prática
Construir um site profissional Elementor com performance real exige decisões técnicas antes mesmo de abrir o editor visual. Meu ponto de partida é sempre o mesmo:
1. Stack enxuta: tema leve + Elementor Pro sem plugins redundantes
Uso o Hello Elementor como tema base — ele foi criado especificamente para isso. Zero CSS de tema disputando espaço com o CSS do Elementor. Sem slider de tema, sem tipografia duplicada, sem header do tema que vai ser sobrescrito de qualquer forma. Cada plugin adicional que entra no projeto precisa justificar sua presença. Se o Elementor Pro já resolve nativamente (formulários, popups, mega menu), não existe plugin extra para isso.
2. Carregamento condicional de assets
O Elementor tem uma opção nativa de carregar CSS por post, em vez de carregar o CSS global em todas as páginas do site. Ativo isso desde o primeiro dia. O resultado direto é que uma página de contato não carrega o CSS do portfólio, e a home não carrega o CSS de um post de blog irrelevante para aquela visita.
3. Imagens tratadas antes de subir, não depois
Nenhuma imagem entra no site sem passar por compressão e conversão para WebP. Não confio só em plugin de otimização de imagem para fazer esse trabalho — eles ajudam na manutenção contínua, mas o upload inicial já precisa ser feito com o arquivo correto. Uma imagem de hero que deveria ter 120KB não pode entrar com 2MB e depender de um plugin para “resolver”.
4. Fontes: máximo duas famílias, carregadas localmente
Fontes do Google carregam de um servidor externo, geram uma requisição DNS extra e podem segurar o render. Hospedo as fontes localmente usando o @font-face com os arquivos WOFF2 no próprio servidor. Isso elimina a dependência externa e reduz o tempo de carregamento real — especialmente em conexões móveis.
5. Lazy load real, não só atributo no HTML
O atributo loading="lazy" nas imagens é o mínimo. O que faço além disso é garantir que nenhum vídeo de fundo, nenhum mapa embutido e nenhum iframe carregue na abertura da página se não estiver na viewport inicial. O Elementor permite isso com configuração nativa de lazy load por seção — mas a maioria dos sites ignora essa opção completamente.
A diferença que o Google mede: Core Web Vitals no Elementor
Os Core Web Vitals — LCP, CLS e INP — são as métricas que o Google usa para avaliar a experiência do usuário e, por consequência, influenciar o ranqueamento. Um site profissional Elementor bem executado consistentemente atinge PageSpeed 90–98 no mobile e 98–100 no desktop. Já documentei esse resultado em projetos reais, e explico o raciocínio técnico por trás disso neste post sobre PageSpeed 95+ e o custo real de um site lento em conversão.
O ponto central é: o Elementor não é o gargalo. O que gera gargalo é ignorar as configurações de performance que o próprio Elementor Pro disponibiliza nativamente — como o sistema de CSS inline para above-the-fold, o carregamento assíncrono de scripts e a desativação de widgets não utilizados.
A diferença que o cliente sente: conversão e percepção de qualidade
Performance não é só número de PageSpeed. É a sensação que o visitante tem ao abrir a página no celular com 4G médio. Se o site travar por 3 segundos antes de mostrar qualquer conteúdo, o visitante já formou uma opinião sobre a empresa — e ela não é boa.
Nos projetos de landing page que entrego, o tempo de carregamento impacta diretamente a taxa de permanência. Na construção da landing page da Dra. Helena, por exemplo, cada decisão de layout foi tomada pensando no peso final da página — não só na aparência. O resultado é um site rápido e que converte, não um portfólio bonito que ninguém aguenta esperar abrir.
O mesmo raciocínio se aplica a sites institucionais. Depois de mais de 170 sites entregues, ficou claro para mim que design com estratégia e código limpo não são coisas separadas — são a mesma coisa vista de ângulos diferentes.
Por que o preconceito com Elementor existe — e o que ele revela
O preconceito com Elementor é real, mas ele vem de um lugar concreto: a maioria dos sites feitos com a ferramenta foi construída por quem aprendeu a usar o editor visual sem nunca ter estudado performance web. A culpa não é do Elementor. É da execução sem critério técnico.
Desenvolvedores que trabalham só com código customizado frequentemente olham para um site profissional Elementor e enxergam “bloat por padrão”. O que eles estão vendo, na verdade, é o resultado de instalações descuidadas — não o teto que a ferramenta permite atingir.
Um site feito com React pode ser lento se os bundles não forem otimizados. Um site em WordPress puro pode ser pesado se o tema for mal codificado. A ferramenta não determina o resultado — o nível técnico de quem executa é o que define se o site vai performar ou não.
Elementor como ferramenta de produção séria: o que a escolha certa de parceiro muda
Escolher um parceiro técnico que domina o Elementor de verdade significa ter um site que carrega rápido, ranqueia e converte — sem abrir mão da flexibilidade visual que o cliente precisa para atualizar conteúdo no futuro sem depender de desenvolvedor para tudo.
Se você quer entender como esse processo funciona do início ao fim, desde o briefing até a entrega com performance validada, documentei cada etapa neste post sobre meu processo de criação de site em 7 dias. E se ainda está na dúvida entre landing page e site institucional para o seu projeto, explico exatamente como tomo essa decisão com cada cliente no briefing.
Um site profissional Elementor bem feito não é uma concessão técnica. É uma escolha estratégica — quando quem executa sabe o que está fazendo.
Quer um site que performa de verdade — não só um site bonito?
Se você precisa de um site profissional com Elementor, código limpo, PageSpeed acima de 95 e estrutura pensada para converter, me chama no WhatsApp. Analiso seu projeto e te digo o que faz sentido para o seu caso — sem enrolação.
→ Falar sobre meu projeto no WhatsApp
Perguntas frequentes
Site profissional feito com Elementor realmente performa bem no Google?
Sim. Um site profissional Elementor bem configurado — com tema leve (Hello Elementor), CSS carregado por post, fontes hospedadas localmente e imagens em WebP — atinge consistentemente PageSpeed 90–98 no mobile e 98–100 no desktop, passando nos Core Web Vitals do Google.
Qual a diferença entre um site profissional Elementor e um Elementor genérico?
O Elementor genérico usa o tema padrão do builder, acumula plugins redundantes e não otimiza assets CSS/JS, resultando em páginas com 4 MB+ de CSS não utilizado e LCP acima de 4 segundos. O site profissional parte de decisões técnicas antes de abrir o editor: stack enxuta, carregamento condicional de assets e imagens otimizadas na origem.
Elementor é mais lento do que um site feito só com código?
Não necessariamente. A performance depende da execução, não da ferramenta. Um site em React com bundles não otimizados ou um WordPress com tema mal codificado pode ser tão ou mais lento do que um Elementor bem configurado. O nível técnico de quem executa é o fator determinante.
Quais configurações do Elementor Pro mais impactam a performance?
As principais são: carregamento de CSS por post (em vez de CSS global em todas as páginas), CSS inline para conteúdo above-the-fold, carregamento assíncrono de scripts, desativação de widgets não utilizados e lazy load nativo por seção. A maioria dos sites ignora essas opções, o que explica grande parte do preconceito com a ferramenta.