Updates do Elementor e o fim do DOM inchado: o que mudou com Containers CSS Grid, assets sob demanda e Speculation Rules.
As atualizações recentes do Elementor (série 3.24 a 3.26+) resolveram a maior crítica histórica da ferramenta: o excesso de wrappers HTML. Ao substituir o modelo antigo de Sections + Columns por Containers Flexbox e CSS Grid nativos, somado ao carregamento condicional de bibliotecas (Swiper, modais e fontes de ícones como SVG inline), conseguimos reduzir o tamanho do DOM em até 64% e manter o INP abaixo de 50ms sem abrir mão da produtividade visual.
Durante anos, desenvolvedores front-end criticaram — com razão — o HTML gerado pelo Elementor. Nas versões antigas baseadas em Seções e Colunas, criar um simples card de três colunas exigia até quatro níveis de <div> aninhadas para cada coluna. Em uma landing page longa, o documento passava facilmente de 2.000 nós no DOM, fazendo o Google PageSpeed disparar o alerta de "Avoid an excessive DOM size".
Nos últimos ciclos de atualização, a engenharia do Elementor mudou radicalmente a fundação do renderizador. Para quem sabe configurar os recursos de performance da versão atual, o código entregue ao navegador é outro.
Da sopa de Divs para o CSS Grid e Flexbox nativos
No modelo antigo, alinhar três blocos lado a lado criava um wrapper para a seção, outro para o container, outro para a linha, outro para a coluna e mais um para o preenchimento interno (.elementor-widget-wrap). Hoje, com o Container em modo CSS Grid, temos uma única tag semântica pai aplicando display: grid diretamente sobre os elementos filhos.
- Menos memória no celular: menos nós no DOM significam menos cálculo de estilo (Recalculate Style) na thread principal do navegador mobile, derrubando o INP (Interaction to Next Paint).
- Layouts assimétricos sem gambiarra: grades editoriais de 12 colunas — como as que uso em projetos para o Reino Unido e indústrias na Paraíba — saem nativamente com
grid-template-columnssem precisar aninhar containers dentro de containers.
Carregamento condicional de scripts e ícones em SVG inline
Outro avanço silencioso das últimas versões foi a limpeza do payload de CSS e JavaScript. Antes, mesmo uma página de texto simples carregava o pacote inteiro do Font Awesome (~90 KB) e a biblioteca de carrossel Swiper.js.
Com a flag de Inline Font Icons ativa, o Elementor injeta apenas os caminhos vetoriais (<svg>) dos ícones realmente presentes naquela URL. Da mesma forma, estilos de widgets e animações passam a ser carregados sob demanda apenas quando o bloco existe na página.
Checklist: o que ativar (e o que evitar) na aba Desempenho e Recursos
Sempre que atualizo ou assumo um projeto em WordPress + Elementor Pro, aplico esta configuração exata para garantir nota A sem risco de FOUC (piscar de tela sem estilo):
// Configuração recomendada em Elementor > Configurações > Desempenho:
1. Impressão de CSS -> Arquivo Externo (aproveita cache de borda)
2. Carregamento de fontes Google -> Desativado (servir woff2 variável local)
3. Ícones de fonte Inline (SVG) -> Ativo (elimina requisição FontAwesome)
4. Carregamento otimizado de DOM -> Ativo
5. Cache de elementos (Widgets) -> Ativo para blocos estáticos (exceto loops dinâmicos por sessão)Perguntas frequentes
Devo converter páginas antigas de Seções para Containers automaticamente num clique?
Nunca diretamente em produção. O conversor automático costuma criar containers intermediários desnecessários para imitar as colunas antigas. O caminho limpo é reconstruir as seções principais usando um único Container Grid no ambiente de homologação.
O recurso de Cache de Elementos do Elementor conflita com o Crocoblock?
Pode conflitar se você ativar o cache estático de widget em uma Listing Grid do JetEngine que depende de parâmetros dinâmicos de usuário ou filtros em tempo real. Para vitrines filtráveis com JetSmartFilters, mantenha o cache do widget dinâmico desativado no nível do elemento.