pular para o conteúdo

Página 78x mais leve: quando trocar o Elementor por PHP puro

Capa: Página 78x mais leve, Elementor vs PHP puro

Cloneei a home de um site que mantenho em Elementor puro — os mesmos 17 widgets, montados por código, com a identidade visual idêntica — só para comparar contra a versão que já rodava direto no tema, em PHP. A página em Elementor ficou com ~550 KB de payload total; a mesma página em PHP puro, ~7 KB. Uma pesa 78 vezes mais que a outra para entregar exatamente o mesmo resultado na tela.

O teste

Não é estimativa: é a mesma página, nos dois motores, medida do mesmo jeito — mesmo navegador, mesma rede, sem cache.

  • Elementor: ~550 KB de payload total.
  • PHP direto no tema (front-page.php, CSS/JS próprios do tema): ~7 KB, 8 requisições, Lighthouse local 98/100/100/100 limpo.

550 KB dividido por 7 KB dá pouco mais de 78. A home ficou no PHP; o Elementor segue valendo para o resto do site — por quê, é o que vem agora.

Quando o Elementor vale a pena

  • A página muda com frequência por quem não programa — o cliente edita sozinho.
  • O layout é montado uma vez e não precisa de performance extrema (página institucional, landing de campanha curta).
  • O ganho de velocidade de edição compensa o custo de payload.

Quando PHP puro vale mais

  • É a home ou a página de maior tráfego do site — cada KB a mais multiplica por visita.
  • O design já está fechado e não muda toda semana.
  • SEO e Core Web Vitals são prioridade — LCP e payload pesam no ranking.
  • Quem mantém a página é você, dev, não o cliente.

De onde vem o peso

Nenhum desses pontos é falha de configuração — é como o motor do Elementor funciona por baixo:

  • CSS gerado por widget, com boa parte de regras que a página nem chega a usar.
  • Uma div de wrapper por camada de widget — onde o PHP puro usa uma só.
  • JS de runtime do editor carregado mesmo fora do modo de edição.
  • Fontes e ícones da biblioteca inteira, não só o que a página usa.

Como decidir na sua página

O roteiro que uso, na ordem:

  1. Monte a mesma página nos dois formatos — ou meça a existente e estime o PHP.
  2. Meça payload total e Lighthouse nas duas, mesma rede, mesmo dispositivo simulado.
  3. Decida por página, não pelo site inteiro: aplique a régua acima uma vez por página de alto tráfego.
  4. Se migrar, mantenha o Elementor no resto do site, onde a edição por quem não é dev importa.
				
					# Chrome DevTools: Network > Disable cache > recarrega > soma a coluna "Transferred"

npx lighthouse https://example.com \
  --only-categories=performance \
  --output=json --output-path=./relatorio.json \
  --chrome-flags="--headless"
				
			

Armadilhas

Duas coisas custaram tempo de verdade nesse teste:

  • O número não é fixo: 78x foi o resultado deste layout, com esta quantidade de widgets. Meça a sua página antes de prometer o mesmo ganho.
  • Migrar de volta não é de graça: se o cliente perde a edição visual, alguém — você — vira o responsável por toda alteração futura na página.

Regra prática: meça antes de migrar. Payload pesado não é sempre problema — só é problema na página que mais gente visita.

Do mesmo assunto

Capa: CDN nem sempre é mais rápido

Tutoriais

13 ago 2026

CDN nem sempre é mais rápido: quando hospedar o script você mesmo

Um script de terceiro carregado por CDN estava atrasando uma
Capa: Camada anti-spam em formulários Elementor sem plugin pago

Elementor, Tutoriais

9 jul 2026

Camada anti-spam em formulários Elementor sem plugin pago

Como parei um flood de bot (650+ leads falsos num
Widgets de blocos atômicos do Elementor V4

Atualizações, Elementor, Tutoriais, Web Design, WordPress

7 fev 2026

Novos widgets de blocos aômicos do elementor V4

🚀 NOVIDADE NO ELEMENTOR V4! Os novos Widgets de Blocos

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *