Elementor ou código puro: qual é melhor para a sua landing page?

Quem pesquisa “landing page Elementor ou código” quase sempre está no mesmo ponto: com uma campanha para subir e sem saber se monta a página num builder ou se paga para ela ser escrita à mão. A resposta curta: para landing page de tráfego pago, código puro costuma entregar mais velocidade, mais controle do trackeamento e menos manutenção. O Elementor ganha quando o seu time precisa editar sozinho com frequência, quando o orçamento ou o prazo estão apertados, ou quando o site já roda em WordPress.

Eu trabalho com os dois caminhos. Desde 2022, já entreguei mais de 200 projetos na INOVAWEB, sempre com a mesma régua: carregar rápido e medir certo. Então este não é um texto contra builder, e sim um guia para decidir pelo que importa a quem paga por tráfego: quanto tempo a página leva para mostrar a oferta.

O que muda na velocidade da landing page#

Uma landing page de tráfego pago tem um trabalho só: mostrar a oferta rápido para quem acabou de clicar no anúncio, muitas vezes no celular e nem sempre com boa conexão. Cada arquivo a mais antes da primeira tela é tempo para a pessoa desistir.

Por que um page builder costuma pesar mais

O Elementor não é lento por definição. O peso vem do jeito que ele funciona: para qualquer pessoa montar qualquer layout arrastando blocos, ele carrega CSS e JavaScript genéricos, envolve os elementos em camadas extras de HTML e roda sobre o WordPress, com tema, PHP e banco de dados montando a página.

Na prática, o problema quase nunca é só o Elementor. É o pacote que vem junto: tema, widgets extras e plugins de formulário, pop-up, slider e cookies. Cada um pode carregar os próprios arquivos em todas as páginas, inclusive onde não é usado. Não por acaso, o PageSpeed Insights costuma apontar CSS e JavaScript não usados em páginas montadas em builder.

Nada disso é culpa de quem montou a página. É o custo da conveniência: o builder precisa estar pronto para tudo, e a sua página paga por isso.

O que o código puro tira do caminho

Uma landing page escrita à mão em HTML, CSS e JavaScript leva só o que aquela página usa: sem biblioteca de widgets, sem plugin, sem banco de dados. Os arquivos podem ser entregues em cache por uma CDN, perto do visitante.

Também fica mais fácil cuidar do que decide a velocidade percebida: imagem principal carregando com prioridade, fontes que não bloqueiam o texto e scripts de terceiros entrando depois do que importa.

Core Web Vitals: a régua que o Google usa

Para não discutir velocidade no achismo, o Google tem as Core Web Vitals. Os limites para uma experiência considerada boa, segundo o web.dev, são:

• LCP (Largest Contentful Paint) de até 2,5 s: o tempo até o maior elemento da primeira tela aparecer, geralmente a headline ou a imagem principal.
• INP (Interaction to Next Paint) de até 200 ms: quanto a página demora para responder a um toque, como abrir o formulário.
• CLS (Cumulative Layout Shift) de até 0,1: quanto o layout se desloca enquanto carrega, como o botão que muda de lugar bem na hora do toque.

O Google recomenda medir no 75º percentil dos acessos, separando celular e desktop. Na prática, três em cada quatro visitas precisam ficar dentro do limite.

Como a velocidade mexe no custo do tráfego pago#

Aqui está a parte que interessa a quem investe em anúncio. Você paga pelo tráfego, por impressão ou por clique, e parte das pessoas desiste antes de a página carregar. O dinheiro saiu da conta, e a oferta nem apareceu.

E o efeito cresce rápido. Uma pesquisa do Google com a SOASTA, de 2017, citada no estudo Milliseconds Make Millions, encomendado pelo Google à Deloitte, mostra que a probabilidade de rejeição aumenta 32% quando o tempo de carregamento passa de 1 para 3 segundos.

No Google Ads

No Google Ads, a classificação do anúncio considera, entre outros fatores, o valor do lance e a qualidade dos anúncios e da página de destino. A experiência na página de destino também compõe o Índice de Qualidade. Página que frustra quem clica trabalha contra você no leilão.

A própria central de ajuda do Google Ads diz que aumentar a velocidade das páginas de destino é uma das formas mais fáceis de melhorar os resultados de anúncios para celular, e cita que, no varejo, um atraso de 1 segundo pode afetar as conversões em mobile em até 20%.

Na Meta

Na Meta, compare duas métricas do Gerenciador de Anúncios: cliques no link, que conta quem tocou no anúncio, e visualizações da página de destino, que só conta quando a página carrega e o pixel dispara. Parte da diferença entre as duas é gente que você pagou para trazer e que foi embora antes de ver a página.

Há também um efeito menos óbvio: se a campanha otimiza para lead ou compra, uma página lenta faz menos eventos chegarem ao pixel e à API de Conversões. Com menos sinal, o algoritmo tem menos informação para encontrar quem converte.

Quando o Elementor é a escolha certa#

Digo isso sem constrangimento: há projetos em que o Elementor é a decisão certa, e eu entrego dentro dele quando é o caso.

• O seu time precisa editar sozinho, com frequência. Se a equipe troca headline, preço e data do evento toda semana, a autonomia do editor visual vale muito.
• O orçamento ou o prazo estão apertados. Para validar uma oferta nova, uma estrutura pronta vai ao ar mais rápido e custa menos no início.
• O site já roda em WordPress. Se o blog ou a área de membros estão lá, a landing page fica no mesmo painel, com o mesmo login e o mesmo fluxo de publicação.
• A verba de mídia é pequena ou a página é um teste. Com pouco tráfego, cada segundo a mais custa menos em valor absoluto, e a flexibilidade pode valer mais.

Nesses casos, o caminho não é fugir do builder, e sim usá-lo com disciplina: tema leve, o mínimo de plugins e as opções de desempenho do próprio Elementor ativadas. Falo disso mais abaixo.

Quando vale ir de código puro#

Código puro faz mais sentido quando a página é peça central de uma operação de tráfego pago:

• Você investe em anúncios de forma contínua. Quanto maior a verba, mais caro fica cada segundo de carregamento, porque a perda se repete a cada clique.
• Performance é requisito, não detalhe. Ficar com folga dentro das Core Web Vitals é mais fácil partindo de uma página enxuta do que tirando peso de uma que já nasceu pesada.
• O trackeamento precisa ser confiável. Em código, eu decido quais scripts entram e em que ordem: Meta Pixel com API de Conversões, GA4, Google Tag Manager ou Cloudflare Zaraz, sem plugin brigando com plugin.
• Você não quer manutenção de plugin. Sem WordPress, não há atualização toda semana nem página quebrando depois de um update, e a superfície de ataque diminui muito.
• O design precisa sair igual ao Figma. O layout vai do Figma ao ar sem as limitações de um template.

É o que eu resumo no meu site como Builder é conveniência. Código é performance.

Os dois caminhos lado a lado

Checklist para decidir#

Responda com sinceridade. Se a maioria das respostas cair de um lado, a decisão está tomada.

1. O seu time vai editar a página toda semana, sem ajuda? Ponto para o Elementor.
2. O site já roda em WordPress e a página precisa ficar no mesmo painel? Ponto para o Elementor.
3. A ideia é testar uma oferta rápido, com verba pequena? Ponto para o Elementor.
4. Você vai investir em Meta Ads ou Google Ads de forma contínua? Ponto para o código puro.
5. A página atual está fora dos limites das Core Web Vitals no celular? Ponto para o código puro.
6. Você depende de eventos precisos, como lead e compra, para otimizar as campanhas? Ponto para o código puro.
7. Quer parar de se preocupar com plugin desatualizado? Ponto para o código puro.

Deu empate? Existe um terceiro caminho: a landing page de tráfego pago em código puro, com datas, preços e links fáceis de trocar, e o restante do site no WordPress.

Já tem uma página no Elementor? Faça isso primeiro#

Antes de refazer tudo, meça e tire o excesso. Muita página em Elementor melhora bastante só com uma boa faxina.

1. Meça no celular. Rode o PageSpeed Insights na URL exata do anúncio e anote LCP, INP e CLS.
2. Corte plugins. Desative o que a landing page não usa: slider, pop-up, um pacote inteiro de widgets para usar um ou dois.
3. Ative as opções de desempenho do Elementor. As versões recentes trazem contêineres Flexbox e Grid no lugar das antigas seções e colunas, cache de elementos, carregamento otimizado de imagens e lazy load de imagens de fundo. Ative uma de cada vez e teste.
4. Cuide da imagem principal. Ela costuma ser o elemento de LCP. Use WebP ou AVIF no tamanho real de exibição e nunca aplique lazy load nela.
5. Enxugue as fontes. Uma família, com dois ou três pesos, carregada do seu próprio servidor.
6. Organize os scripts de terceiros. Centralize pixel, GA4 e chat no Google Tag Manager ou no Cloudflare Zaraz, e remova o que ninguém usa.
7. Coloque cache e CDN na frente. Cache de página e uma CDN como a Cloudflare reduzem o tempo de resposta.

Se, depois disso, a página seguir fora dos limites no celular, aí vale reescrevê-la em código.

Conclusão: escolha pela campanha, não pela ferramenta#

Elementor e código puro não são times rivais. São ferramentas com custos diferentes: o builder cobra em peso e manutenção; o código cobra em desenvolvimento e em depender de alguém para mudanças maiores.

Para uma landing page que recebe tráfego pago todos os dias, velocidade deixa de ser detalhe técnico e vira custo de mídia. Nesse cenário, eu escolho código puro. Para um time que precisa de autonomia total ou para um site que já vive no WordPress, o Elementor bem configurado resolve.

Quer ver como isso fica na prática? Veja os projetos que já entreguei e o meu processo, do Figma ao ar. Se ainda estiver em dúvida, me chame para um orçamento: eu avalio a sua página atual e digo qual caminho faz mais sentido para a sua campanha.