−72% NO LCP MOBILE
O conteúdo principal passou a aparecer em 2,8s, contra 9,8s na versão em Elementor.
METADE DO PESO EM HTML
De 178 KB para 92 KB na mesma página, com o mesmo layout e o mesmo formulário.
24 PARA 6 FOLHAS DE ESTILO
O Elementor injeta um CSS por widget. O Block Theme entrega tudo com seis.
10 segundos
até o visitante ver a página
Uma landing page de captura tem um trabalho: levar o visitante até o formulário. Na versão em Elementor, o visitante mobile esperava cerca de 10 segundos pelo conteúdo principal. O gargalo estava na camada de renderização. A hospedagem foi a mesma antes e depois.
As três saídas possíveis, e onde duas delas param:
Plugin de cache
O que parece: resolve sem tocar em código.
onde falhaComprime o que o page builder gera. Não muda o que ele gera. O peso continua sendo produzido a cada requisição.
OTIMIZAR O ELEMENTOR
O que parece: mantém o time no editor que já conhece.
onde falhaEnquanto cada widget carregar a própria folha de estilo, o teto de performance é do Elementor, não do time.
Block Theme
O que parece: reconstruir dá trabalho.
o que entregaMesmo layout com CSS controlado pelo tema, sem duplicação e sem plugin de renderização no caminho.
Otimização superficial não alcança as causas que geram o peso. A migração atuou nas causas.
Antes e depois, nas métricas
que se repetem.
Números de uma das LP do case, no PageSpeed Insights com mediana de 5 ou mais testes. Os ganhos estruturais se repetiram nas 3 LPs.
O que foi removido da página
PESO DO HTML
178 KB para 92 KB. Metade do peso servido ao visitante anônimo, com o mesmo layout e o mesmo formulário.
FOLHAS DE ESTILO
24 para 6. O Elementor injeta uma por widget. No Block Theme o CSS é do tema, sem duplicação.
SCRIPTS (SRC)
21 para 14. Sete arquivos a menos disputando a thread principal durante o carregamento.
PLUGINS DE RENDERIZAÇÃO
Astra e Elementor para nenhum. Nada entre o WordPress e o HTML que chega ao visitante.
O tema foi afinado,
não só migrado
Cada otimização entrou por pull request, revisada e autorizada. Um page builder não oferece esse controle.
-
WEBGL DO HERO OTIMIZADO
Compilação de shader em tempo ocioso, loop que para depois da revelação e pausa fora da viewport. Fim do scripting perpétuo que prejudicava a interatividade.
-
WEBGL ADIADO ATÉ A 1ª INTERAÇÃO
O canvas só inicializa quando o visitante rola ou toca na tela. Derrubou o TBT mobile em 82% na mediana e eliminou os picos de 13s.
-
TAGS DE MARKETING DEFERIDAS
Facebook Pixel, Clarity e LinkedIn passam a carregar na primeira interação. GA e Mautic seguem imediatos, com atribuição preservada.
-
CSS NÃO CRÍTICO FORA DO RENDER-BLOCKING
Tailwind e fontes saem do caminho de renderização. Speed Index 25% menor no mobile e 52% menor no desktop.
-
OPEN SANS SELF-HOSTED
Fim da dependência do Google Fonts: ganho no Speed Index e em privacidade, sem IP de visitante indo para terceiros (LGPD).
Por que um print do PageSpeed
não prova nada
O Total Blocking Time é uma métrica de laboratório notoriamente instável. Rodamos a mesma página 9 vezes sem mudar nada, e o TBT mobile variou 20 vezes: de 230 ms a 13.270 ms. Por isso o comparativo se ancora na mediana e nas métricas estáveis, nunca num print isolado.
Há também um dado que muitos cases omitiriam: a migração inicial piorou o TBT. Foi a afinação do tema que trouxe a métrica de volta à paridade com o Elementor.
Como medimos
PageSpeed Insights, mobile e desktop, mediana de 5 ou mais testes. Mesma régua antes e depois, sem troca de ferramenta e sem escolher o melhor teste.
MESMAS 3 URLS POR ETAPA DO FUNIL
ToFu (apache-vs-nginx), MoFu (checklist-auditoria-llm) e BoFu (kit-para-migrar).
MESMA FERRAMENTA
PageSpeed Insights (Lighthouse), mobile e desktop, antes e depois.
MEDIANA DE 5 OU MAIS testes
Com cache quente, para as métricas voláteis (TBT e Speed Index). O payload estrutural foi medido no HTML servido ao visitante anônimo.
DADOS DE CAMPO (CRUX): AINDA NÃO HÁ
As URLs não atingem o volume de tráfego que o Google exige para o percentil 75. O comparativo é de laboratório.
Migração feita. E a sua operação?
Se o seu time publica landing pages em page builder, o custo aparece em três lugares: segundos até o formulário no mobile, peso por página e dependência de plugin para renderizar.
Esse é o método que aplicamos em operações WordPress: medir com mediana, atacar a camada que gera o peso e colocar cada ajuste sob controle de versão: Medimos, Migramos, Afinamos e Documentamos.
dúvidas sobre a migração
Seu page builder está custando segundos no mobile?
Conta pra gente onde você quer chegar. Em até 24 horas úteis, um especialista volta com um plano inicial. Sem proposta padrão, sem follow-up automático.