Elementor Pro para ASC Theme: O que Mudou no Nosso Site
TL;DR
A migração do Elementor para tema próprio é a troca do construtor visual Elementor Pro por um tema feito sob medida, que entrega as páginas sem a camada do construtor. Aqui mostramos o que mudou em cinco páginas do nosso site com o ASC Theme, do HTML à semântica, a nova medição feita dois meses depois e os limites do caso.
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.
Em cinco páginas do site felipecferreira.com.br, a troca do Elementor Pro pelo ASC Theme, em 23/07/2026, reduziu o HTML em 47,9%, os elementos renderizados no mobile em 43,9% e os bytes transferidos no mobile em 62,8%; na Home, o LCP mobile de laboratório (tempo até o maior elemento da tela aparecer) foi de 5,6 s no registro com Elementor para 1,7 s nas três medições de 30/09/2026. O 5,6 s não tem print da tela de métricas.
“Se o site está funcionando, por que mexer na estrutura inteira e sair do Elementor Pro?”
Essa pergunta é justa. Um page builder (construtor visual, ferramenta para montar páginas arrastando blocos) acelera a criação e pode entregar um design competente.
O problema aparece quando a operação acumula atualizações, add-ons (extensões), correções de cache (a cópia pronta das páginas, servida sem gerar tudo de novo), 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 como foi a migração do Elementor para tema próprio aqui em casa: saímos do Elementor Pro para o ASC Theme e medimos o antes, o logo depois e, dois meses depois, de novo.
Não é uma disputa universal entre ferramentas. É um estudo de caso observacional (sem grupo de controle) do nosso próprio site, com cinco páginas medidas em produção.
O que este texto não cobre: o passo a passo da migração, a comparação com outros construtores visuais, custos, CPU, memória e dados de campo de usuários reais.
Tudo aqui é a nossa experiência, com um servidor, um cache e um conteúdo específicos. Ferramentas de teste do Google, como PageSpeed Insights e Lighthouse, mudam de versão com frequência, e cada site (servidor, plugins, cache, conteúdo) precisa ser tratado como um caso próprio.
Nota de revisão (30/09/2026): esta versão corrige três pontos da publicação original (folhas de estilo da Home, leitura do tempo de resposta do servidor e número de execuções do PageSpeed Insights) e acrescenta as cinco páginas, as camadas de estrutura do Elementor, a semântica e uma nova medição feita dois meses depois.
Então vem comigo e vamos detalhar estes aspectos juntos!
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 só para corrigir efeitos de outras ferramentas. É o mesmo acúmulo que aparece quando fazemos a higienização de WordPress em pastas, banco e filas.
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 envio de emails.
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
Com a migração, o site passou a ser montado pelo ASC Theme, uma estrutura própria organizada para o nosso conteúdo, responsividade e requisitos de SEO. Na arquitetura do WordPress, o tema é a camada que monta o HTML de cada página; com o ASC Theme, o page builder saiu do caminho.
O ASC Theme é um projeto proprietário, com arquitetura e desenvolvimento feitos por mim, Felipe Ferreira: não é vendido no mercado, não é público, não é gratuito e não está em nenhum repositório do GitHub.
O frontend (a parte do site que chega ao navegador do visitante) 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 e mantivemos só a infraestrutura de SMTP (o protocolo de envio de email) que a operação exige; é relato operacional, não medido nesta coleta.
- Tema orientado a SEO: os requisitos de SEO passaram a integrar a arquitetura. Depois da migração, ainda rodamos um diagnóstico interno de metadados; os números estão no registro do diagnóstico SEO/GEO do nosso site.
- Servidor mantido: o servidor web LiteSpeed continuou o mesmo, com o Cloudflare (CDN, rede de distribuição de conteúdo) na frente, antes e depois.
Mas não saiu só o Elementor.. Para ler os números com honestidade, você precisa saber o que mudou junto, na mesma virada:
- CookieYes: o plugin de cookies CookieYes estava nas cinco páginas com Elementor e não aparece em nenhuma página com o ASC Theme;
- Trustindex: o widget (componente pronto) de avaliações saiu da página Sobre (continua na Home);
- Conteúdo: o texto de Sobre encolheu 56,8%, o da Biblioteca cresceu 183,1%, e a Home ganhou título novo (de “Bem-vindo” para “Engenharia em Aquisição de Clientes Online”) e menu novo (de 8 para 6 itens no topo).
Parte da queda de scripts e bytes vem dessas saídas, não do tema. Vou apontar isso onde pesa.
O staging (ambiente de testes) com o ASC Theme 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.
Como Medimos o Antes e o Depois
Medimos em três momentos, sempre em produção. Cutover é a virada, o momento em que o site novo substitui o antigo no ar:
- A, conjunto
A_PRODUCAO_ELEMENTOR: dados de produção antes da migração, com Elementor; - C, conjunto
C_PRODUCAO_ASC: dados de produção depois da migração, com o ASC Theme, minutos depois do cutover; - D: nova medição do PageSpeed Insights da Home com o ASC Theme, dois meses depois.
No resto do texto, A e C são a forma curta de A_PRODUCAO_ELEMENTOR e C_PRODUCAO_ASC.
Nos dois conjuntos, coletamos das cinco páginas (Home, Biblioteca, Sobre, Deep Research e Política de Privacidade) o HTML bruto (o código como sai do servidor), os headers HTTP (os cabeçalhos que acompanham a resposta), o texto extraído e o DOM (a árvore de elementos que o navegador monta) renderizado em desktop (1440 px) e mobile (390 px).
Na mesma coleta, registramos o inventário de recursos de cada carregamento, isto é, as requests (requisições de arquivos e serviços feitas pelo navegador) e os bytes de cada uma.
O PageSpeed Insights (PSI), ferramenta do Google que roda o Lighthouse em condições simuladas de laboratório, foi executado só na Home: três vezes por dispositivo em A, uma vez em C e três vezes em D.
Na tabela abaixo, hit significa que a página saiu pronta do cache do servidor; miss, que ela foi gerada na hora.
Método e Limites em Um Quadro
| Item | A | C | D |
|---|---|---|---|
| Data | 23/07 | 23/07 | 30/09 |
| Coleta das 5 páginas | 22:25 a 22:27 | 23:33 a 23:35 | não houve |
| Cache do LiteSpeed | hit | miss | não registrado |
| PSI por dispositivo | 3 vezes | 1 vez | 3 vezes |
| Horário do PSI | 22:23 a 22:32 | 23:39 e 23:42 | 20:02, 20:21 e 20:40 |
| Lighthouse | 13.4.0 | não aparece | 13.5.0 |
| Prints do PSI | só notas | só notas | notas e métricas |
Os limites que você precisa ter em mente ao ler tudo o que vem abaixo:
- Cache diferente: A saiu do cache do LiteSpeed (
hit) e C foi gerado na hora (miss); por isso o TTFB ficou fora da comparação. - Conteúdo e plugins diferentes: CookieYes, Trustindex em Sobre e as reescritas de texto mudaram junto com o tema.
- Borda do Cloudflare: o Cloudflare fica na frente do LiteSpeed; em A, todas as respostas vieram do POP (ponto de presença) de Guarulhos (GRU); em C, de GRU e do Rio de Janeiro (GIG).
- Lighthouse mudou: 13.4.0 em A e 13.5.0 em D; a versão de C não aparece nos prints.
- Sem dados de campo: o CrUX (Chrome User Experience Report, base de dados de usuários reais do Chrome) mostrou “No Data” em A, C e D.
- Métricas sem print: os tempos de carregamento de A e C (FCP, LCP e TBT, explicados na seção da medição de 30/09/2026) foram transcritos do registro da coleta; os prints de A e C mostram só as notas.
Por isso, este é um estudo observacional, não um experimento controlado.
Faz sentido? Então vamos aos números.
O que Mudou no Código Entregue ao Navegador
Nas cinco páginas, o HTML caiu de 694.446 para 362.121 bytes (47,9% a menos), e os elementos renderizados no mobile, de 3.437 para 1.927 (43,9% a menos). Tudo isso sem perda de texto no conjunto.
O texto extraído, somado, subiu de 31.702 para 33.689 caracteres (6,3% a mais). O que encolheu foi a estrutura em volta do conteúdo.
HTML e DOM nas Cinco Páginas
Página por página, o HTML bruto encolheu nas cinco, de 31,8% em Deep Research a 60,1% em Sobre.
| Página | A (bytes) | C (bytes) | Queda |
|---|---|---|---|
| Home | 159.807 | 87.195 | 45,4% |
| Biblioteca | 120.499 | 64.873 | 46,2% |
| Sobre | 161.538 | 64.376 | 60,1% |
| Deep Research | 138.664 | 94.603 | 31,8% |
| Política de Privacidade | 113.938 | 51.074 | 55,2% |
| Total | 694.446 | 362.121 | 47,9% |
Comprimido em zstd (o formato de compressão que o servidor usou na entrega), o HTML das cinco páginas foi de 140.454 para 89.710 bytes, 36,1% a menos.
Nos elementos renderizados no mobile, a queda foi menor em Biblioteca e Deep Research (27,8% e 34,6%), porque o conteúdo dessas páginas cresceu. Mesmo assim, as duas caíram.
| Página | A | C | Queda |
|---|---|---|---|
| Home | 700 | 367 | 47,6% |
| Biblioteca | 626 | 452 | 27,8% |
| Sobre | 703 | 316 | 55,0% |
| Deep Research | 865 | 566 | 34,6% |
| Política de Privacidade | 543 | 226 | 58,4% |
| Total | 3.437 | 1.927 | 43,9% |
O texto mudou junto com o tema, e para os dois lados: cresceu na Home, na Biblioteca e em Deep Research e encolheu em Sobre e na Política de Privacidade.
| Página | A | C | Variação |
|---|---|---|---|
| Home | 6.510 | 7.522 | 15,5% a mais |
| Biblioteca | 1.578 | 4.467 | 183,1% a mais |
| Sobre | 6.506 | 2.813 | 56,8% a menos |
| Deep Research | 10.998 | 12.926 | 17,5% a mais |
| Política de Privacidade | 6.110 | 5.961 | 2,4% a menos |
| Total | 31.702 | 33.689 | 6,3% a mais |
Os recursos carregados no mobile caíram de 486 para 194 (60,1% a menos), com queda parecida em todas as páginas.
| Página | A | C | Queda |
|---|---|---|---|
| Home | 96 | 42 | 56,3% |
| Biblioteca | 99 | 37 | 62,6% |
| Sobre | 105 | 38 | 63,8% |
| Deep Research | 99 | 40 | 59,6% |
| Política de Privacidade | 87 | 37 | 57,5% |
| Total | 486 | 194 | 60,1% |
Os div renderizados, somados, foram de 1.058 para 164 (84,5% a menos). Na Home, de 248 para 40.
Uma correção em relação à primeira versão: a Home com o ASC Theme carrega 2 folhas de estilo, não 12. O HTML tem 12 tags <link>, mas só 2 são rel="stylesheet"; a comparação certa na Home é de 29 para 2 folhas de estilo (93,1% a menos).
Menos Código de Terceiros no Carregamento
Somando as cinco páginas, o que sumiu do carregamento foi isto:
- Scripts externos: de 81 para 11 (86,4% a menos), sendo 5 dos 81 do CookieYes, um por página; na Home, de 16 para 3;
- Script inline (JavaScript escrito dentro do próprio HTML): de 247.748 para 37.714 bytes (84,8% a menos);
- Folhas de estilo: de 151 para 10 (93,4% a menos); cada página C carrega 2, a da biblioteca de blocos do WordPress e a do ASC Theme;
- jQuery: saíram os 3 arquivos da biblioteca (jQuery, jQuery Migrate e jQuery UI Core);
- Google Fonts: saíram as famílias carregadas pelo builder (Roboto, Roboto Slab, PT Sans, Open Sans e Montserrat na Home; a página Sobre carregava ainda a Poppins).
Nem tudo caiu.. e isso também precisa estar aqui. O CSS inline (estilo escrito dentro do HTML) subiu de 71.915 para 86.916 bytes, 20,9% a mais.
Quase todo esse aumento está em Deep Research (de 14.383 para 26.392 bytes); nas outras quatro páginas, foram 748 bytes a mais em cada uma.
Na Home C, os 3 scripts externos que sobraram são o do ASC Theme, o do widget Trustindex e um script do próprio Cloudflare que protege endereços de email.
Transferência no Mobile e no Desktop
Os bytes transferidos no mobile, somados, caíram de 4.156.083 para 1.546.669 (de cerca de 4,16 MB para 1,55 MB, 62,8% a menos). No desktop, de 3.954.279 para 2.091.151 (47,1% a menos).
Bytes transferidos são o que o navegador precisou receber naquela execução. Não são conta de CDN, custo financeiro nem consumo total de infraestrutura.
| Página | A (bytes) | C (bytes) | Queda |
|---|---|---|---|
| Home | 887.160 | 283.975 | 68,0% |
| Biblioteca | 798.781 | 220.293 | 72,4% |
| Sobre | 942.247 | 412.839 | 56,2% |
| Deep Research | 852.568 | 409.246 | 52,0% |
| Política de Privacidade | 675.327 | 220.316 | 67,4% |
| Total | 4.156.083 | 1.546.669 | 62,8% |
| Página | A (bytes) | C (bytes) | Queda |
|---|---|---|---|
| Home | 765.249 | 487.227 | 36,3% |
| Biblioteca | 693.339 | 220.235 | 68,2% |
| Sobre | 967.501 | 757.045 | 21,8% |
| Deep Research | 958.377 | 406.303 | 57,6% |
| Política de Privacidade | 569.813 | 220.341 | 61,3% |
| Total | 3.954.279 | 2.091.151 | 47,1% |
Uma ressalva importante: a queda foi bem menor na Home desktop (36,3%) e em Sobre desktop (21,8%). Em C, Biblioteca, Deep Research e Política de Privacidade transferem quase os mesmos bytes nos dois viewports. Sobre não: 412.839 no mobile e 757.045 no desktop, 344 KB a mais. A Home repete o desenho, com 203 KB a mais no desktop. Esta coleta não separa qual recurso explica esses dois resíduos.
Em A, os arquivos do Elementor respondiam por 48,0% da transferência mobile somada, 1.996.865 bytes (cerca de 2,0 MB): 43,1% na Home, 48,1% na Biblioteca, 47,9% em Sobre, 46,9% em Deep Research e 56,1% na Política de Privacidade.
Eram 220 arquivos do builder no carregamento desktop e 1.865 elementos do builder no DOM; em C, zero.
Dos 2.609.414 bytes que deixaram de ser transferidos no mobile, 1.996.865 (76,5%) são arquivos do Elementor que sumiram. O restante é CookieYes, fontes, jQuery e conteúdo, já descontado o que o ASC Theme colocou no lugar.
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.
Quantos Wrappers o Elementor Colocava em Volta do Texto?
Até sete. Nas cinco páginas com Elementor, o texto ficava dentro de uma cadeia de até 7 wrappers do builder aninhados, e os wrappers somavam 600 elementos; no ASC Theme, zero.
Wrapper é um elemento HTML que existe só para envolver outro, normalmente para posicionar ou estilizar. No Elementor, são as camadas de seção, container, coluna, área do widget, widget e conteúdo do widget.
Veja o caminho até o título principal da Home nos dois momentos. Em A, como a Home não tinha H1, o caminho é o do primeiro H2:
<!-- Antes (A, Elementor): 7 wrappers do builder até o título -->
<body class="home">
<div class="elementor elementor-4236">
<section class="elementor-section elementor-top-section">
<div class="elementor-container">
<div class="elementor-column">
<div class="elementor-widget-wrap">
<div class="elementor-element elementor-widget">
<div class="elementor-widget-container">
<h2 class="elementor-heading-title">
<!-- Depois (C, ASC Theme): sem wrappers do builder -->
<body class="home">
<main class="site-main">
<article class="home-page">
<header class="home-hero">
<div class="o-container home-hero__inner">
<div class="home-hero__content">
<h1 class="c-page-hero__title">Figura 2: caminho até o título principal da Home, com sete wrappers do Elementor em A e main, article e header no ASC Theme. Fonte: coleta do autor, 23/07/2026 (trecho reduzido às linhas do caminho).
Quer uma analogia? É como receber um presente dentro de sete caixas, uma dentro da outra: o conteúdo é o mesmo, mas o navegador precisa abrir, medir e estilizar cada caixa.
Na prática, a profundidade mediana de parágrafos, títulos e itens de lista caiu de 11 para 8 níveis. Os tokens de classe (cada nome de classe CSS escrito no HTML) foram de 4.102 para 1.677, 59,1% a menos.
Havia ainda o que o JavaScript montava depois que o HTML chegava. Em A, de 172 a 269 elementos por página eram injetados no carregamento; em C, de 6 a 12.
| Página | Wrappers em A | divem A | divem C |
|---|---|---|---|
| Home | 161 | 248 | 40 |
| Biblioteca | 93 | 191 | 55 |
| Sobre | 139 | 234 | 18 |
| Deep Research | 112 | 222 | 37 |
| Política de Privacidade | 95 | 163 | 14 |
| Total | 600 | 1.058 | 164 |
div renderizados no desktop, por página. Fonte: coleta do autor, 23/07/2026.“Injetados por JS” é a diferença entre os elementos renderizados no desktop e os elementos do HTML original. Não é uma prova de lentidão, mas é trabalho a mais que o navegador faz depois de receber a página.
| Página | Tokens A → C | JS A → C |
|---|---|---|
| Home | 983 → 360 | 174 → 7 |
| Biblioteca | 820 → 464 | 174 → 7 |
| Sobre | 881 → 266 | 179 → 12 |
| Deep Research | 797 → 396 | 269 → 7 |
| Política de Privacidade | 621 → 191 | 172 → 6 |
| Total | 4.102 → 1.677 | 968 → 39 |
Semântica e Acessibilidade: o Conteúdo Principal Ficou Detectável
A semântica foi o ganho mais claro para SEO e para GEO (otimização para motores generativos, como os assistentes de IA): com Elementor, nenhuma das cinco páginas tinha o landmark main; com o ASC Theme, as cinco têm.
Landmark é uma região da página marcada no HTML com um papel definido (main, nav, header, footer). Leitores de tela usam essas regiões para pular direto ao conteúdo principal.
Nas outras quatro páginas, o texto fora do main fica entre 739 e 823 caracteres. Na Home são 5.460: 7.522 no texto extraído e 2.062 dentro do main. Esta coleta não separa o que compõe esses cerca de 4.700 caracteres a mais. A primeira hipótese é o widget Trustindex, que saiu de Sobre e continuou na Home.
O restante da estrutura seguiu o mesmo caminho:
- H1: Home e Biblioteca não tinham H1 em A; em C, as cinco páginas têm exatamente 1;
- Hierarquia de títulos: as cinco páginas A tinham saltos (de h2 para h4, de h1 para h3, página começando em h2 ou h3); nenhuma página C tem;
- Accessibility no PSI da Home: 86 em A, 100 em C e 100 em D;
- Agentic Browsing (grupo de auditorias do PSI para navegação por agentes de IA): 2/3 em A, 3/3 em C e em D. Pelo painel da coleta, a auditoria que falhava em A era a da árvore de acessibilidade (Accessibility tree).
| Página | mainA / C | H1 A / C | Texto nomain em C |
|---|---|---|---|
| Home | 0 / 1 | 0 / 1 | 2.062 |
| Biblioteca | 0 / 1 | 0 / 1 | 3.672 |
| Sobre | 0 / 1 | 1 / 1 | 2.067 |
| Deep Research | 0 / 1 | 1 / 1 | 12.103 |
| Política de Privacidade | 0 / 1 | 1 / 1 | 5.222 |
main e H1 por página, em A e em C, e texto dentro do main em C, em caracteres (medição desktop). Fonte: coleta do autor, 23/07/2026.Os saltos de título em A, página por página:
- Home: começava em h2 e saltava de h2 para h4;
- Biblioteca: começava em h3;
- Sobre: saltava de h2 para h4, duas vezes;
- Deep Research: saltava de h2 para h4;
- Política de Privacidade: saltava de h1 para h3.
O que não mudou: o JSON-LD (dados estruturados no formato JSON) é idêntico em A e C nas cinco páginas, gerado pelo Yoast. Se você quer entender esse lado, o guia de JSON-LD para SEO, GEO e AEO aprofunda.
Então o ganho de “SEO na arquitetura” aqui não é de dados estruturados. É de marcação: região principal, um H1 por página e títulos em ordem.
Por que isso importa para GEO? Muitas ferramentas de extração de conteúdo procuram o main e a hierarquia de títulos para separar o conteúdo do resto da página.
Um limite honesto: não medimos o efeito dessa mudança em citações por IA nem em ranking. O que medimos é que, antes, a marcação não dizia onde estava o conteúdo, e agora diz.
O Resultado no PageSpeed Insights Logo Após o Cutover
Na Home, a nota de Performance foi de 52 para 92 no mobile e de 73 para 88 no desktop, comparando a mediana de três execuções A com uma única execução C.
Isso é uma indicação de laboratório, não uma série equivalente. As três execuções A deram 50, 52 e 52 no mobile e 73 nas três no desktop.
| Nota da Home | A mediana de 3 | C 1 execução |
|---|---|---|
| Performance mobile | 52 | 92 |
| Performance desktop | 73 | 88 |
| Accessibility | 86 | 100 |
| Best Practices mobile | 81 | 81 |
| Best Practices desktop | 77 | 81 |
| SEO | 92 | 92 |
Um ponto que a primeira versão não deixava claro: no cutover, a Accessibility subiu de 86 para 100 nos dois dispositivos. O SEO ficou em 92. Best Practices ficou em 81 no mobile e, no desktop, subiu de 77 para 81.
Os tempos de carregamento de A e C (FCP, LCP e TBT) estão nas tabelas da medição de 30/09/2026, lado a lado com D.
Por que o TTFB Ficou Fora da Comparação
O TTFB (Time to First Byte, tempo até o primeiro byte da resposta do servidor) não entra nesta comparação, porque ele mediu o estado do cache, não o tema.
E aqui mora um erro da primeira versão deste texto.
Nas capturas imediatas, as cinco páginas A foram servidas pelo cache do LiteSpeed (x-litespeed-cache: hit, TTFB entre 0,206 e 0,239 s). Já as cinco páginas C foram geradas sem cache (miss, entre 0,434 e 1,464 s), minutos depois do cutover.
| Página | TTFB A (s) cache hit | TTFB C (s) cache miss |
|---|---|---|
| Home | 0,239 | 1,464 |
| Biblioteca | 0,210 | 0,434 |
| Sobre | 0,235 | 0,533 |
| Deep Research | 0,206 | 0,436 |
| Política de Privacidade | 0,224 | 0,517 |
# A, Elementor: Home, 23/07/2026 22:25 BRT, TTFB 0,239 s
x-litespeed-cache: hit
# C, ASC Theme: Home, 23/07/2026 23:33 BRT, TTFB 1,464 s
x-litespeed-cache: missFigura 5: o header de cache da Home nos dois momentos; A saiu do cache (hit) e C foi gerado na hora (miss), por isso o TTFB não entra na comparação. Fonte: coleta do autor, 23/07/2026.
O que o dado diz, e só isso: logo após a virada, a Home C levou 1,464 s para ser gerada sem cache. O TTFB sem cache de A nunca foi medido, então não dá para dizer que o servidor ficou mais lento.
Dois Meses Depois: a Medição de 30/09/2026
Os ganhos de carregamento se mantiveram em laboratório. Em 30/09/2026, 69 dias depois da virada, o FCP e o LCP mobile da Home ficaram em 1,7 s nas três execuções, e a Performance mobile teve mediana 89.
Rodamos o PSI da Home três vezes por dispositivo, às 20:02, 20:21 e 20:40 (BRT), com Lighthouse 13.5.0 e, no mobile, um Moto G Power emulado em rede Slow 4G (celular intermediário simulado numa rede 4G lenta). Antes da execução das 20:21, o cache foi limpo.
As siglas das duas tabelas a seguir: FCP (First Contentful Paint, primeiro conteúdo visível), LCP (Largest Contentful Paint, maior elemento visível) e TBT (Total Blocking Time, tempo em que a thread principal fica bloqueada por tarefas longas).
Speed Index mede a rapidez com que o conteúdo aparece na tela; CLS (Cumulative Layout Shift) mede o quanto o layout “pula” durante o carregamento.
| Mobile | A | C | D, mediana (mín. a máx.) |
|---|---|---|---|
| Performance | 52 | 92 | 89 85 a 91 |
| FCP (s) | 4,7* | 1,7* | 1,7 1,7 a 1,7 |
| LCP (s) | 5,6* | 1,7* | 1,7 1,7 a 1,7 |
| TBT (ms) | 630* | 270* | 370 350 a 540 |
| Speed Index (s) | n/d | n/d | 2,1 2,1 a 3,3 |
| CLS | n/d | n/d | 0 0 a 0 |
| Accessibility | 86 | 100 | 100 100 a 100 |
| Best Practices | 81 | 81 | 100 100 a 100 |
| SEO | 92 | 92 | 100 100 a 100 |
| Desktop | A | C | D, mediana (mín. a máx.) |
|---|---|---|---|
| Performance | 73 | 88 | 80 79 a 92 |
| FCP (s) | 0,9* | 0,5* | 0,5 0,5 a 0,5 |
| LCP (s) | 1,1* | 0,8* | 0,5 0,5 a 0,9 |
| TBT (ms) | 570* | 280* | 450 230 a 450 |
| Speed Index (s) | n/d | n/d | 0,9 0,9 a 0,9 |
| CLS | n/d | n/d | 0 0 a 0 |
| Accessibility | 86 | 100 | 100 100 a 100 |
| Best Practices | 77 | 81 | 100 100 a 100 |
| SEO | 92 | 92 | 100 100 a 100 |
| Agentic Browsing | 2/3 | 3/3 | 3/3 3/3 a 3/3 |
(*) Transcrito do registro da coleta, sem print da tela de métricas. Para A, não é possível confirmar se são a mediana das três execuções ou os valores de uma execução específica.
Boa notícia, mas com asterisco. O que a medição D mostra, e o que ela não mostra:
- Carregamento estável: FCP e LCP mobile iguais nas três execuções e iguais ao registro de C, contra 4,7 e 5,6 s em A;
- O 88 desktop de C foi atípico: a mediana D é 80 (de 79 a 92), principalmente por causa do TBT (mediana de 450 ms). O ganho desktop de A para D existe, mas é modesto: 7 pontos;
- O TBT é a métrica que oscila: de 350 a 540 ms no mobile e de 230 a 450 ms no desktop, no mesmo dia. Os 270 ms de C no mobile ficaram abaixo das três execuções D, então uma execução única não deve ancorar o TBT;
- Best Practices e SEO chegaram a 100 só em D: não dá para atribuir isso ao tema. Algo mudou entre 23/07 e 30/09 (ajustes posteriores, a troca do Lighthouse 13.4 pelo 13.5, ou os dois), e a causa ainda é incerta;
- Cache limpo: a execução logo após a limpeza (20:21) teve o TBT mais alto (540 e 450 ms), mas com uma execução por condição não dá para culpar o cache frio.
Ainda não decompusemos o TBT atual por script. É o próximo ponto que vamos investigar, porque hoje ele é o que mais separa a Home da faixa satisfatória ou ótima no desktop (notas de 90 a 100, na classificação por cores da própria interface do PSI).
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, e a marcação medida confirma isso (
main, H1 e títulos em ordem).
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 isto: 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 do Elementor para tema próprio 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: no conjunto de ferramentas, 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 (página de campanha) 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 (o caminho de volta, se algo der errado). Migrar apenas para perseguir uma nota PSI é uma justificativa fraca.
Na prática, é esse levantamento que eu faço quando um cliente cogita trocar a arquitetura do site: entender ferramentas, dependências e gargalos antes de decidir, o diagnóstico que descrevo em Tecnologia Aplicada.
O que Ainda Não Podemos Concluir
Este caso tem limites explícitos, e eles valem tanto quanto os números:
- Não é controle experimental: tema, plugins (CookieYes), conteúdo e estado do cache mudaram juntos.
- Não é prova universal: os dados são do nosso domínio e não representam todos os sites Elementor.
- Não é campo: o CrUX mostrou “No Data” em A, C e D; não temos dado de usuário real para falar de Core Web Vitals.
- Não é distribuição completa: o PSI foi só da Home, e C teve uma execução por dispositivo.
- Não explica Best Practices e SEO: as duas notas chegaram a 100 depois do cutover, por um motivo que não isolamos.
- 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.
Nota de Método e Como Repetir no Seu Site
Para registro: em A e C, o HTML, os headers e os tempos de resposta foram coletados com o curl (ferramenta de linha de comando que faz a requisição), e o DOM e o inventário de recursos, com um navegador automatizado nas larguras de 1440 px e 390 px. O PSI foi rodado pela interface pública do Google.
As contagens foram feitas com o parser (leitor de HTML) html5lib, que monta a mesma árvore que o navegador. Excluímos o <template> inerte do widget Trustindex, contamos como folha de estilo só o <link rel="stylesheet"> e chamamos de wrapper todo elemento com classe de estrutura do Elementor.
Quer repetir o exercício no seu site? O roteiro mínimo é este:
- salve o HTML e os headers de cada página e anote o estado do cache (no LiteSpeed,
x-litespeed-cache); - compare antes e depois só com o mesmo estado de cache;
- conte
<link rel="stylesheet">e<script src>, não todas as tags<link>; - confira se existe um único
maine um único H1, e se os títulos seguem em ordem; - rode o PSI pelo menos três vezes por dispositivo e use a mediana, sempre anotando data, hora e versão do Lighthouse.
Conclusão: Menos Camadas, Mais Controle
No nosso site, a migração do Elementor Pro para o ASC Theme reduziu HTML, elementos renderizados, recursos e transferência nas cinco URLs medidas. E deu às páginas uma estrutura semântica que antes não existia.
Na Home, o carregamento de laboratório melhorou no cutover e continuava no mesmo patamar dois meses depois. Já Best Practices e SEO chegaram a 100 por outro caminho, que ainda não sabemos explicar..
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.
Isso não transforma Elementor em vilão nem ASC Theme em atalho. O construtor pode ser adequado para um contexto; para o nosso, 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.
Se você está pesando uma troca parecida, conte seu contexto pelo botão de WhatsApp desta página e vamos entender qual caminho faz sentido para o seu momento.
Perguntas frequentes
A Migração Prova que Elementor é Sempre Lento?
Não. Ela mostra o que observamos em cinco páginas do nosso próprio site antes e depois da troca. Tema, plugins, conteúdo e estado do cache mudaram juntos, então o caso não isola o Elementor como causa única.
Posso Usar o ASC Theme no Meu Site?
Não. O ASC Theme é um projeto proprietário, com arquitetura e desenvolvimento de Felipe Ferreira: não é vendido no mercado, não é público, não é gratuito e não está em nenhum repositório do GitHub.
Os Ganhos se Mantiveram Depois do Cutover?
Sim, em laboratório. Em 30/09/2026, o FCP e o LCP mobile da Home ficaram em 1,7 s nas três execuções do PageSpeed Insights, contra 4,7 s e 5,6 s com Elementor. O TBT, porém, variou de 350 a 540 ms no mobile no mesmo dia.
O Estudo Mediu Core Web Vitals Reais?
Não. O PageSpeed Insights entregou só dados de laboratório, e o CrUX mostrou “No Data” nas três medições, então não temos dado de usuário real para falar de Core Web Vitals.
Devo Migrar Meu Site para um Tema Próprio?
Depende. Avalie manutenção, dependências, integrações, equipe, orçamento e risco da migração. Reconstruir só para buscar uma nota de laboratório não justifica o trabalho.
Referências
- Google for Developers, About PageSpeed Insights: dados de laboratório e de campo (CrUX) e limiares das métricas.
- Chrome for Developers, Total Blocking Time: o que o TBT mede e como o Lighthouse o classifica.
- Chrome for Developers, Lighthouse performance scoring: pesos da nota e por que ela varia entre execuções.
- web.dev, Time to First Byte (TTFB): definição do TTFB e das fases que ele soma.
- W3C WAI, ARIA Authoring Practices Guide: Landmark Regions: papel do
maine das demais regiões. - Coleta própria em produção: conjuntos
A_PRODUCAO_ELEMENTOReC_PRODUCAO_ASC(23/07/2026) e medição D do PageSpeed Insights (30/09/2026); e a experiência do autor na operação do site.