Em Elementor vs Gutenberg, a diferença de performance está na arquitetura. O Gutenberg salva os blocos como HTML no conteúdo do post, então a maior parte da página já é marcação pronta, e o WordPress consegue carregar CSS só dos blocos que aparecem. O Elementor salva o layout como dados em post meta e renderiza tudo por widgets em PHP, com invólucros próprios, uma camada de scripts no front-end e CSS por página. Isso dá ao Gutenberg um ponto de partida mais leve em DOM, CSS e JavaScript. Não quer dizer que todo site em blocos seja rápido: bibliotecas de blocos pesadas, sliders e scripts de terceiros custam o mesmo nos dois. Meça os seus templates antes de decidir refazer.
Minha resposta curta: o editor define o piso, e quem monta o site define todo o resto. Abaixo comparo como cada um gera a página, onde fica o custo e o que medir. Este artigo faz parte do guia de como acelerar o WordPress.
Como cada editor guarda e renderiza a página?
É daqui que vem a diferença de performance, então vale ser preciso.
O Gutenberg guarda o conteúdo em post_content como HTML, com os delimitadores de bloco escritos como comentários HTML. Blocos estáticos são salvos como marcação final, então na hora de renderizar o WordPress basicamente interpreta os delimitadores e entrega o HTML. Blocos dinâmicos, como o de posts recentes ou o de navegação, rodam uma função PHP de renderização a cada requisição. Os estilos vêm das folhas de estilo de cada bloco e dos estilos globais que o WordPress gera a partir do theme.json.
O Elementor guarda o layout como JSON em post meta (_elementor_data) e renderiza cada elemento por uma classe PHP de widget quando a página é montada. O CSS é gerado por página e por kit, como arquivo na pasta de uploads ou embutido no HTML, conforme o método de impressão de CSS configurado. No front-end ele carrega scripts próprios para animações, popups, elementos fixos e comportamento responsivo.
| Aspecto | Gutenberg (blocos) | Elementor |
|---|---|---|
| Onde fica o layout | HTML no conteúdo do post | JSON em post meta |
| Caminho de renderização | Quase tudo é marcação salva; PHP só nos blocos dinâmicos | Classe PHP de widget para cada elemento |
| Marcação | HTML de bloco, em geral um invólucro por bloco | Invólucros de container ou seção, coluna e widget |
| CSS | Folha de estilo por bloco mais estilos globais do theme.json | CSS do front-end, CSS do kit e um arquivo gerado por página, mais o CSS dos widgets |
| JavaScript | Nenhum na maioria dos blocos do core; Interactivity API (WordPress 6.5) para blocos que precisam | Scripts do front-end para widgets, efeitos de movimento e recursos do Pro |
| Fontes | Fontes do tema, e a Font Library desde o WordPress 6.5 | Fontes do kit, por padrão vindas do Google Fonts se você não mudar |
O que isso significa para o tamanho do DOM?
Um título dentro de um bloco de grupo no Gutenberg são dois elementos: o grupo e o título. O mesmo título num container do Elementor é o container, mais o invólucro do widget, mais o título, e os layouts antigos de seção e coluna somam mais níveis. O Container Flexbox e a saída de DOM otimizada do Elementor fecharam boa parte dessa distância, mas na maioria dos sites Elementor antigos que eu audito os templates foram montados antes disso e nunca foram refeitos.
O tamanho do DOM pesa mais no INP. Cada interação que muda estilo ou layout obriga o navegador a recalcular sobre mais nós. Num notebook rápido você não percebe; num Android intermediário isso aparece nos dados de campo.
E o CSS e o JavaScript?
Temas de bloco carregam só o CSS dos blocos do core que aparecem na página, e temas clássicos podem ativar o mesmo comportamento. A maioria dos blocos do core não precisa de JavaScript nenhum. Quando um bloco precisa de interação, a Interactivity API oferece um runtime pequeno e compartilhado, em vez de um script por plugin.
O Elementor tem versões próprias dessa ideia: carregamento condicional dos scripts e do CSS dos widgets e ícones em SVG inline no lugar de fontes de ícones. Com isso ligado, a distância diminui. O que sobra é a camada base que o Elementor carrega para rodar os widgets e o arquivo CSS por página. Nenhum dos dois é grande num site bem montado. Mesmo assim, é mais do que um tema de bloco envia para o mesmo conteúdo.
Onde o Gutenberg perde a vantagem?
O editor de blocos deixa de ser leve quando o pessoal instala coisas por cima. Os casos que mais vejo:
- Plugins de biblioteca de blocos que carregam o CSS e o JavaScript de todos os blocos em todas as páginas, mesmo quando a página usa um só
- Construtores de página feitos como blocos, que trazem de volta um sistema de layout e invólucros próprios
- Sliders, carrosséis e blocos de animação, que custam o mesmo JavaScript em qualquer editor
- Scripts de terceiros, como chat, gerenciador de tags e anúncios, que nenhuma escolha de editor resolve
- Tema clássico com uma folha de estilo enorme, em que o HTML dos blocos é leve mas o CSS não
Então um site em Gutenberg com quatro bibliotecas de blocos e um tema pesado pode ficar mais lento que um site Elementor bem cuidado. Quando comparo os dois para um cliente, olho os templates reais, não o nome do editor.
Como comparar os dois no seu próprio site?
Não confie em comparação de duas páginas de demonstração, nem nas minhas. Monte o mesmo template real nos dois, com o mesmo tema, as mesmas fontes e as mesmas imagens, e meça:
- tamanho do DOM de cada template, pelo Lighthouse
- total de CSS e JavaScript transferido, e quanto disso não é usado, pelo painel Coverage do Chrome DevTools
- quantidade de requisições no caminho crítico antes do LCP
- TTFB numa requisição sem cache, que mostra o custo de renderização em PHP
- INP dos dados de campo depois que a página estiver no ar, porque ferramenta de laboratório só estima o custo de interação
Rode os testes de laboratório várias vezes e com limitação de rede e CPU de celular. Uma rodada só varia demais para decidir alguma coisa. A diferença entre laboratório e campo está explicada em field data vs lab data.
Elementor vs Gutenberg em performance: quando faz sentido cada um?
| Situação | O que costumo recomendar |
|---|---|
| Site institucional novo, com equipe que consegue trabalhar com blocos | Tema de bloco com blocos do core e patterns |
| Site Elementor que já passa nos Core Web Vitals | Manter; ajustar templates e add-ons |
| Site Elementor reprovando no INP mobile | Refazer primeiro os templates de mais tráfego com containers; pensar em blocos só se isso não bastar |
| Site em que editores sem perfil técnico montam layouts novos toda semana | Os dois servem; o hábito de quem edita pesa mais que a ferramenta |
| Portal de conteúdo com milhares de posts | Editor de blocos nos posts; o template decide mais a performance do que o editor do post |
Migrar um site no ar do Elementor para blocos é refazer o site, não virar uma chave. Planeje como um redesign, com redirecionamentos e conferência de conteúdo, e faça só quando as medições mostrarem que o Elementor ajustado ainda não passa. Se você vai continuar no Elementor, como acelerar o Elementor lista as correções na ordem em que eu aplico, e Core Web Vitals no Elementor vai métrica por métrica.
Perguntas frequentes
O Gutenberg é mais rápido que o Elementor?
Com o mesmo design e sem plugins extras, um tema de bloco costuma enviar menos HTML, CSS e JavaScript. Se isso aparece nos seus Core Web Vitals depende do resto: hospedagem, cache, imagens e scripts de terceiros muitas vezes pesam mais.
Trocar para o Gutenberg melhora o SEO?
Não diretamente. O Google ranqueia conteúdo e usa os Core Web Vitals como um sinal entre muitos. Se a troca corrige um LCP ou INP reprovado, ajuda na parte de experiência da página. Não resolve conteúdo nem links.
O Elementor consegue passar nos Core Web Vitals?
Consegue. Um site Elementor com containers, poucos add-ons, fontes locais e servidor com cache passa no mobile. Exige mais disciplina que um tema de bloco, principalmente na montagem dos templates.
Se você precisa de uma resposta direta para o seu site, com medição em vez de opinião sobre construtor, a minha auditoria de performance WordPress compara os seus templates reais e diz se ajustar basta ou se refazer compensa.