Elementor Pro para ASC: O que Mudou no Nosso Site

“Se o site está funcionando, por que mexer na estrutura inteira e sair do Elementor Pro?”

Essa pergunta é justa. Um page builder (ferramenta visual para montar páginas) acelera a criação e pode entregar um design competente. O problema aparece quando a operação acumula atualizações, add-ons, correções de cache, conflitos e dependências que ninguém consegue explicar com segurança.

Foi exatamente esse o ponto de partida do nosso próprio site. Este texto conta a migração do Elementor Pro para o tema ASC, uma migração do Elementor para tema próprio, com observações do trabalho e uma coleta técnica de antes e depois.

Não é uma disputa universal entre ferramentas. É um estudo de caso observacional antes/depois do nosso próprio site. A gente mediu o que estava em produção com Elementor, migrou para o ASC e mediu novamente em produção.

Então vem comigo e vamos detalhar estes aspectos juntos!

NOTA TÉCNICA: Todas as informações contidas aqui retratam a minha experiência e o meu método de trabalho, você é o total responsável por alterações no seu site ou no site de seus clientes. Nos responsabilizamos exclusivamente em parcerias formalizadas por contratos. Em dúvida, visite o Aviso Legal.

Por que a Arquitetura Entrou na Conversa

O trabalho não começou com a ideia de que todo site Elementor é lento. Começou com uma pergunta mais operacional: quantas camadas o nosso site precisava carregar para entregar cada página?

No ambiente antigo, Elementor Free e Pro exigiam atualizações frequentes. Na carteira de clientes, esse ritmo aumentava manutenção e risco operacional. Também vimos projetos com add-ons, plugins de formulário, plugins de email e ferramentas instaladas para corrigir efeitos de outras ferramentas.

Há ainda o problema do licenciamento irregular no ecossistema de clientes. Alguns freelancers instalavam cópias falsificadas ou crackeadas, o que bloqueava atualizações legítimas e agravava a exposição a vulnerabilidades. Isso é um risco operacional de licenciamento, não uma característica intrínseca do Elementor.

No nosso site, a rotina também incluía problemas de cache e a necessidade de atualizar ou regenerar a biblioteca do Elementor. Em alguns projetos, encontramos conflitos com plugins de cookies e com componentes usados no processamento de formulários e payloads de email.

A relação entre arquitetura e execução fica mais fácil de separar quando usamos o método de camadas do protocolo L0 a L7. Um HTML grande é um sintoma observável; ele não prova sozinho que uma única ferramenta causou todo o tempo de carregamento.

O que Mudou na Migração

O ASC é uma estrutura própria, organizada para o nosso conteúdo, responsividade e requisitos de SEO. O page builder saiu do caminho e o frontend passou a depender do tema, do WordPress e de um conjunto menor de recursos.

A mudança envolveu decisões concretas:

• Estrutura própria: o page builder foi substituído por uma estrutura própria, mais limpa, organizada, responsiva e orientada a desempenho.
• Menos dependências: eliminamos a necessidade de plugins extras de email, mantendo a infraestrutura SMTP necessária.
• Tema orientado a SEO: os requisitos de SEO passaram a integrar a arquitetura.
• Servidor constante: mantivemos o LiteSpeed, para contextualizar a comparação sem tratá-la como experimento controlado.

O staging com ASC foi útil para diagnosticar a arquitetura. Mas não o usamos como prova causal, porque domínio, cache, conteúdo e condições de execução não eram equivalentes. A comparação publicável é entre A, produção com Elementor antes do cutover, e C, produção com ASC imediatamente depois.

Como Medimos o Antes e o Depois

A coorte teve cinco URLs do site, Home, Biblioteca, Sobre, Deep Research e Política de Privacidade, cada uma observada em mobile e desktop.

Coletamos HTML bruto, headers, texto extraído, DOM (árvore de elementos que o navegador renderiza), inventário de recursos e screenshots. Também preservamos capturas completas da interface do PageSpeed Insights e o HTML dos relatórios. Na Home, registramos ainda a rede, isto é, as requests (requisições de arquivos e serviços feitas pelo navegador).

O baseline A teve três execuções de PageSpeed Insights por URL e dispositivo. PSI é um teste de laboratório, executado em condições simuladas. O pós-cutover C tem evidência HTTP e DOM imediata para toda a coorte, mas apenas uma execução PSI da Home por dispositivo.

Por isso, o estudo não apresenta uma distribuição estável de desempenho. Também não afirma mudança em Core Web Vitals de campo. Para isso, seriam necessários dados correspondentes de CrUX ou Search Console, que não fazem parte deste pacote.

Nota metodológica: os dados instrumentados deste estudo vêm de um dossiê interno de coleta A/C do nosso próprio domínio. O material não é público; por isso, os resultados devem ser lidos com as limitações descritas acima.

O que Apareceu no HTML e no DOM

No material observado deste caso, a Home com Elementor apresentava mais wrappers, classes, scripts e folhas de estilo do que a Home após o cutover. Os números abaixo descrevem essa diferença, sem atribuí-la como regra a todo construtor visual.

Na Home antiga, o HTML tinha 159.807 bytes, 342 div no código-fonte e 700 elementos renderizados no navegador. Também havia 29 scripts e 29 links de folhas de estilo na fonte, além de 96 recursos observados no mobile.

Na mesma página após o cutover, o HTML tinha 87.195 bytes, 145 div na fonte e 367 elementos renderizados no mobile. A fonte passou a listar 11 scripts e 12 folhas de estilo, enquanto a coleta registrou 42 recursos no mobile.

A mudança não significa que o novo site tenha menos texto. Na Home, o texto extraído cresceu de 6.510 para 7.522 caracteres. O que caiu foi a camada estrutural medida junto do conteúdo.

Na coorte mobile, o padrão observado foi este:

Na coleta imediata, todas as páginas C deixaram de apresentar recursos e elementos identificados como próprios do Elementor. Isso confirma a troca de arquitetura no material observado. Não confirma, sozinho, que cada ganho de velocidade veio exclusivamente do tema.

O que Aconteceu com a Transferência

Bytes transferidos são uma medida mais próxima daquilo que o navegador precisou receber naquela execução. Eles não são uma conta de CDN, custo financeiro ou consumo total de infraestrutura.

Na Home mobile, a transferência renderizada caiu de 887.160 para 283.975 bytes. Na Biblioteca, foi de 798.781 para 220.293 bytes. Na página Sobre, de 942.247 para 412.839 bytes.

O mesmo padrão apareceu nas demais páginas, com uma ressalva importante: a redução foi menor na Home desktop e em Sobre desktop do que em algumas páginas mobile. O navegador, a negociação de protocolo, cache e o momento da coleta influenciam esse número.

A redução de requests também explica parte da manutenção menor. Há menos arquivos para versionar, menos dependências para atualizar e menos combinações possíveis entre scripts, CSS, plugins e cache.

O Resultado no PageSpeed Insights

Aqui precisamos ser especialmente precisos. A comparação de PSI abaixo coloca a mediana de três execuções A ao lado de uma única execução C da Home. Isso é uma indicação laboratorial, não uma série temporal equivalente.

O resultado é consistente com uma página que entrega menos estrutura e menos recursos de builder ao navegador. Ainda assim, a própria coleta mostra por que não devemos transformar o número em promessa. O TTFB (tempo até o primeiro byte da resposta) da Home foi de aproximadamente 0,239 s em A e 1,464 s em C.

Ou seja, o frontend ficou menor na evidência observada, mas a resposta inicial do servidor estava mais lenta na execução C. O servidor LiteSpeed foi mantido, porém cache, conteúdo, plugins e outras condições de execução não foram controlados como em um experimento.

O que a Experiência Operacional Ensinou

Os números ajudam a localizar o mecanismo. A experiência diária explica por que a migração valeu o trabalho para nós.

• Manutenção: atualizar Elementor Free e Pro deixou de fazer parte da rotina do site.
• Menos quebras: na nossa experiência, houve menos quebras no frontend.
• Cache e regeneração: não dependemos da mesma rotina de atualizar ou regenerar a biblioteca do builder.
• Email: eliminamos a necessidade de plugins extras de email, mantendo a infraestrutura SMTP necessária à operação.
• SEO: a nova estrutura foi projetada com requisitos de SEO incorporados à arquitetura.

Alunos e clientes também deram feedback espontâneo de que o site parecia mais rápido, inclusive no mobile, além de perceberem melhoria no layout e no design. Esse relato é qualitativo e anedótico. Não foi pesquisa estruturada e não é prova de Core Web Vitals de campo.

O aprendizado principal foi menos “um tema próprio sempre vence” e mais dependência também é uma métrica operacional. Cada plugin adicional pode aumentar requests, conflitos e trabalho de manutenção, mesmo quando o visitante não vê a origem do problema.

Quando uma Migração Assim Faz Sentido

Esta não é uma recomendação para reconstruir qualquer site que use Elementor. A migração tende a fazer sentido quando:

• O site é estratégico: o negócio precisa controlar arquitetura, conteúdo, performance e evolução por mais tempo.
• A manutenção virou investigação: cada atualização exige regenerar CSS, limpar cache ou testar combinações.
• O stack cresceu sem desenho: Elementor, add-ons e plugins de correção passaram a cumprir papéis sobrepostos.
• Há equipe para manter o código: um tema próprio troca dependência de fornecedor por responsabilidade técnica interna.

Ela pode não fazer sentido quando o objetivo é publicar rapidamente uma landing page descartável, quando o orçamento não comporta reconstrução ou quando não há quem mantenha a nova estrutura.

A decisão precisa considerar conteúdo, integrações, acessibilidade, SEO, formulários, analytics, cache, hospedagem e plano de rollback. Migrar apenas para perseguir uma nota PSI é uma justificativa fraca.

O que Ainda Não Podemos Concluir

Este caso tem limites explícitos:

• Não é controle experimental: LiteSpeed ficou constante, mas houve mudanças simultâneas de tema, plugins, conteúdo e camadas de cache.
• Não é prova universal: os dados são do nosso domínio e não representam todos os sites Elementor.
• Não é campo: PSI mede laboratório. Não temos série de CrUX ou Search Console suficiente para atribuir melhora em Core Web Vitals.
• Não é distribuição C: a coorte C tem evidência HTTP e DOM imediata, mas PSI foi executado uma vez apenas na Home em cada dispositivo.
• Não é auditoria de infraestrutura: não medimos CPU, memória, CDN, economia financeira ou porcentagem de manutenção.

Também não usamos o staging B para sustentar a conclusão. Ele serviu para diagnosticar a arquitetura antes do cutover, com uma execução por URL e condições que não eram equivalentes à produção.

Conclusão: Menos Camadas, Mais Controle

No nosso site, a migração do Elementor Pro para o ASC reduziu HTML, elementos renderizados, recursos e transferência observados em uma coorte de cinco URLs. A Home também teve uma execução PSI de laboratório melhor após o cutover, embora a amostra seja assimétrica e o TTFB tenha piorado naquele momento.

O ganho que percebemos não é apenas uma nota. É a combinação de menos HTML e DOM, menos requests, menos dependências e menos pontos de quebra. Na nossa experiência, a migração trouxe menos manutenção e menos quebras no frontend.

Isso não transforma Elementor em vilão nem ASC em atalho. O construtor pode ser adequado para um contexto. Para o nosso contexto, a arquitetura própria passou a responder melhor ao que precisávamos manter, medir e evoluir.

A pergunta útil não é qual ferramenta vence no geral. É qual estrutura você consegue operar com clareza daqui a dois anos.

Perguntas frequentes

A Migração Prova que Elementor é Sempre Lento?

Não. Ela mostra o que observamos no nosso próprio site antes e depois da troca. Conteúdo, cache, plugins, servidor e condições de execução também influenciam desempenho.

O LiteSpeed Foi Trocado Junto com o Tema?

Não. O servidor LiteSpeed foi mantido. Isso ajuda a contextualizar a comparação, mas não cria controle experimental, porque outras variáveis mudaram.

O Estudo Mediu Core Web Vitals Reais?

Não. PageSpeed Insights fornece dados de laboratório. Não coletamos uma série de campo em CrUX ou Search Console que permita afirmar melhora de Core Web Vitals reais.

Por que o HTML Pode Ficar Menor sem Reduzir o Conteúdo?

Porque HTML inclui estrutura, wrappers, classes e referências a recursos além do texto. Na nossa Home, o texto extraído cresceu enquanto o HTML e os elementos renderizados diminuíram.

Devo Migrar Meu Site para um Tema Próprio?

Depende. Avalie manutenção, dependências, integrações, equipe, orçamento e risco de migração. Reconstruir só para buscar uma nota de laboratório não é suficiente para justificar o trabalho.