--- title: "Elementor vs Gutenberg em performance: o que a arquitetura muda" id: "587" type: "post" slug: "elementor-vs-gutenberg-performance-pt" published_at: "2026-10-06T20:00:49+00:00" modified_at: "2026-10-06T20:22:48+00:00" url: "https://danielpazwp.com/pt/elementor-vs-gutenberg-performance-pt/" markdown_url: "https://danielpazwp.com/pt/elementor-vs-gutenberg-performance-pt.md" excerpt: "Como Elementor e Gutenberg guardam e renderizam a página, o efeito disso no DOM, no CSS e no JavaScript e como comparar os dois nos seus templates." taxonomy_category: - "Performance" --- [Performance](https://danielpazwp.com/pt/category/performance-pt/) 7 min de leitura # Elementor vs Gutenberg em performance: o que a arquitetura muda Como Elementor e Gutenberg guardam e renderizam a página, o efeito disso no DOM, no CSS e no JavaScript e como comparar os dois nos seus templates. Publicado **06/10/2026**7 min de leitura [Escrito porDaniel Paz](https://danielpazwp.com/pt/author/daniel-paz/) 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](https://danielpazwp.com/pt/como-acelerar-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](https://danielpazwp.com/pt/core-web-vitals-dados-de-campo-vs-laboratorio/) . ## 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](https://danielpazwp.com/pt/como-acelerar-elementor/) lista as correções na ordem em que eu aplico, e [Core Web Vitals no Elementor](https://danielpazwp.com/pt/core-web-vitals-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](https://danielpazwp.com/pt/auditoria-performance-wordpress/) compara os seus templates reais e diz se ajustar basta ou se refazer compensa. [Trabalhe com o Daniel](https://danielpazwp.com/pt/#book) [Mais em Performance](https://danielpazwp.com/pt/category/performance-pt/) [Sobre o autorPágina do autor](https://danielpazwp.com/pt/author/daniel-paz/) ## Artigos relacionados [Todos os artigos](https://danielpazwp.com/pt/artigos/) [Performance out 2026Page cache vs object cache vs edge cache: qual você precisa](https://danielpazwp.com/pt/page-cache-object-cache-edge-cache-qual-voce-precisa/) [Performance out 2026Core Web Vitals: dados de campo vs laboratório](https://danielpazwp.com/pt/core-web-vitals-dados-de-campo-vs-laboratorio/) [Performance out 2026WordPress lento: os motivos estruturais e a ordem para corrigir](https://danielpazwp.com/pt/por-que-seu-wordpress-e-lento-motivos-estruturais/)