Elementor lento quase nunca é culpa do Elementor: é medição do carregamento errado. Cache quente e cache frio são dois sites diferentes, e o visitante do Google pega o frio. Na nossa medição, TTFB de 1247 ms no frio contra 220 ms no quente, e o carregamento completo de terceiros em 3283 ms contra 1300 ms. Só preconnect e dns-prefetch levaram o frio a 2251 ms. São 18 causas em quatro blocos, e a ordem que rende é: cache de página, aquecimento do cache, preconnect, e só então mexer no Elementor.
- Cache quente e cache frio são dois sites: medir só o quente esconde 1 segundo de TTFB.
- Na nossa medição, o cache frio custou 1247 ms de TTFB contra 220 ms no quente — 5,6x.
- Preconnect e dns-prefetch nos domínios de terceiro derrubaram o carregamento frio de 3283 ms para 2251 ms, sem tocar em imagem.
- As cinco primeiras causas não têm nada a ver com Elementor: cache, aquecimento, purge, object cache e PHP.
- Lazy load na primeira imagem da página sabota o LCP em vez de ajudar.
- Combinar e adiar JavaScript é a única otimização de alto risco da lista — deixe por último e valide página a página.
- wp_options com autoload acima de 1 MB é sinal amarelo e só aparece no cache frio.
Elementor lento quase nunca é o Elementor — é a hora em que você mediu
A cena se repete: o cliente diz que o site está arrastado, você abre o PageSpeed Insights, vê verde, roda de novo e vê verde outra vez. Aí você responde “está rápido aqui” e a conversa acaba sem solução. Elementor lento, na maioria dos casos que chegam assim, não é um problema de construtor de páginas: é um problema de qual carregamento foi medido.
Existem dois sites dentro do mesmo site. O cache quente é a página que já foi pedida por alguém há pouco e está guardada pronta no servidor — é o que você mede quando dá F5 três vezes seguidas. O cache frio é a página que ninguém pediu ainda, ou que acabou de ser publicada, ou que perdeu o cache porque você editou uma linha: o servidor precisa acordar o PHP, consultar o banco, montar o HTML e só então responder.
O visitante que vem do Google, do Discover ou de um link de WhatsApp recém-compartilhado cai quase sempre no segundo caso. Você mede o primeiro. Daí o diagnóstico nunca fechar.
Aqui no WPRaiz medimos os dois, no nosso próprio site (WordPress + Elementor + LiteSpeed), como visitante deslogado, em ciclos de 30 minutos ao longo de três horas. Os números estão abaixo, e são a espinha deste artigo — nenhuma das 18 causas é chute de checklist genérico.
Os números que separam o site rápido do site que parece rápido
Medição de julho de 2026, artigo real do blog, navegador limpo com User-Agent de Chrome. Nada de sessão de administrador: a barra do admin e os scripts extras do painel inflam tudo e não representam ninguém que visita o site.
| Cenário | TTFB | 1º script de terceiro pronto | Cabeçalho de cache |
|---|---|---|---|
| Cache frio (1º acesso / pós-publicação) | 1247 ms | 3283 ms | x-litespeed-cache: miss |
| Cache quente (acessos seguintes) | ~220 ms | ~1300 ms | x-litespeed-cache: hit |
Leia de novo a primeira coluna: 1247 ms contra 220 ms. O mesmo site, o mesmo Elementor, os mesmos plugins, a mesma hospedagem — 5,6 vezes mais lento para responder o primeiro byte. Tudo que vem depois (CSS, fonte, imagem, script de terceiro) começa 1 segundo atrasado e nunca recupera.
Outros números do mesmo carregamento frio, que vão importar nas causas: 76 requisições, cerca de 1 MB de peso, 40 scripts, 6 folhas de estilo, e três arquivos JavaScript bloqueando a renderização dentro do <head> (jquery.min.js, jquery-migrate.min.js e o shim de compatibilidade do Font Awesome 4). Zero erros de console — o site está “correto”, e mesmo assim lento.
E o resultado da intervenção, para você saber o tamanho do prêmio: só com preconnect e dns-prefetch nos domínios de terceiro, o carregamento frio caiu de 3283 ms → 2617 ms → 2251 ms em três ciclos de medição, e o mobile fechou em 2230 ms. Uma mudança de cinco linhas no <head> comprou quase 1 segundo. Nenhuma imagem foi recomprimida para isso.
Antes de tocar em qualquer causa: meça o frio e o quente
Dois comandos, trinta segundos, e você já sabe em qual dos dois sites está trabalhando.
# 1) Cache quente: peca a pagina duas vezes e olhe o cabecalho
curl -sI -A "Mozilla/5.0" https://seusite.com.br/uma-pagina/ | grep -i -e litespeed -e cf-cache -e age
# 2) Cache frio: forca um MISS com query string unica + mede o tempo
curl -s -o /dev/null -w "TTFB %{time_starttransfer}s TOTAL %{time_total}sn"
-A "Mozilla/5.0" "https://seusite.com.br/uma-pagina/?frio=$(date +%s)"Se o TTFB do segundo comando for três, cinco, dez vezes o do primeiro, pare de procurar widget pesado: o seu problema está nas causas 1 a 5. Se os dois forem parecidos e altos, é hospedagem ou banco. Se os dois forem baixos e o site ainda “parece” lento, a dor está no que carrega depois — causas 6 a 18.
Causas 1 a 5: a infraestrutura responde antes do Elementor existir
- Não existe cache de página. É o maior ganho isolado e o mais ignorado. Sem cache de página, todo visitante paga o PHP inteiro. Com cache, o servidor devolve um arquivo pronto. No nosso caso é a diferença entre 1247 ms e 220 ms de TTFB. Fix: LiteSpeed Cache, WP Rocket, W3 Total Cache ou o cache do próprio host — qualquer um, ligado e verificado pelo cabeçalho de resposta.
- O cache existe mas nunca aquece. Esta é a causa que quase nenhum tutorial cobre e que mais dói em site que publica com frequência: a página nova nasce fria e o primeiro visitante paga a conta. Fix: ligar o crawler do plugin de cache apontando para o sitemap. A documentação do crawler do LiteSpeed explica o intervalo e o limite de carga; em outros plugins o recurso costuma se chamar “preload”.
- O cache é purgado a cada edição. Cada vez que você salva algo no Elementor, o plugin de cache limpa tudo — e o site inteiro volta ao frio. Em site que recebe ajuste diário, isso significa que boa parte do tráfego sempre pega o caminho lento. Fix: configurar o purge para ser cirúrgico (só a URL editada e o que depende dela) em vez de “purge all”, e rodar o crawler logo depois.
- Falta object cache. Quando o cache de página não pega — visitante logado, carrinho, página de busca —, o PHP volta a consultar o banco do zero. Redis ou Memcached guardam o resultado das consultas e cortam o TTFB frio de forma expressiva. Fix: habilitar Redis no painel do host e ativar o módulo de object cache do seu plugin.
- PHP antigo ou com pouca memória. Elementor monta layout em PHP; versão velha do interpretador e limite de memória apertado transformam qualquer página complexa em espera. Fix: PHP 8.2 ou superior, OPcache ligado,
memory_limitde pelo menos 256M. A documentação oficial de otimização do WordPress detalha o que cada camada realmente afeta.
Repare no padrão: nenhuma dessas cinco é sobre Elementor. Se você começar pelas causas seguintes sem resolver estas, vai passar o dia otimizando imagem para ganhar 80 ms enquanto 1000 ms sangram no TTFB.
Causas 6 a 10: o que o Elementor carrega em toda página
- Improved Asset Loading e Optimized DOM Output desligados. São os dois interruptores mais baratos do Elementor: o primeiro só carrega o CSS/JS dos widgets realmente usados na página; o segundo enxuga a quantidade de
<div>que o construtor cospe. A documentação do Elementor sobre os dois recursos explica o que cada um muda no HTML final. Fix: Elementor → Configurações → Recursos, ligar os dois e testar o site inteiro depois. - Seções aninhadas sem necessidade. Container dentro de container dentro de container é o vício mais comum de quem monta no olho. Cada nível vira
<div>com classe, regra de CSS e cálculo de layout. Fix: abrir o navegador de estrutura do editor e achatar tudo que existe só para “dar um espacinho” — margem resolve sem criar nó novo. - Widget pesado onde um bloco simples serviria. Carrossel, contador animado, galeria com lightbox e formulário carregam bibliotecas próprias. Três widgets desses no topo da página e você importou meia dúzia de arquivos antes do texto aparecer. Fix: reservar widget pesado para onde ele converte, não para decorar.
- Global Widgets e templates carregados em página que não usa. Cabeçalho, rodapé e popup do Elementor Pro entram em todo lugar por padrão. Um popup configurado para “todo o site” carrega o motor de popup em todas as páginas, mesmo nas que nunca vão abri-lo. Fix: revisar as condições de exibição de cada template e restringir ao que faz sentido.
- Conflito de plugin que sobra do editor. Pacotes de complementos de Elementor (addons) costumam carregar a biblioteca inteira mesmo quando você usa dois widgets. Nosso levantamento dos 10 bugs mais comuns do Elementor Pro mostra que boa parte da queixa de lentidão no editor nasce aí — e o que pesa no editor costuma pesar no visitante também. Fix: desativar tudo menos Elementor, medir, e religar um a um. Vale conferir também a compatibilidade do Elementor Pro com temas e plugins antes de acusar o construtor.
Causas 11 a 14: imagens, fontes e terceiros
- Imagem enviada no tamanho original. Uma foto de 4000 px servida num container de 800 px é o clássico. O navegador baixa tudo e joga fora 80% do que baixou. Fix: redimensionar antes do upload, servir WebP ou AVIF, e conferir se o tema está gerando os tamanhos intermediários.
- Lazy loading na imagem errada. Adiar imagem que está abaixo da dobra é certo; adiar a imagem do topo é sabotar o próprio LCP, porque o navegador só começa a baixar o elemento principal depois de calcular o layout. A documentação do LCP no web.dev é explícita sobre isso. Fix: excluir a primeira imagem do lazy load e, se possível, dar
fetchpriority="high"a ela. - Fonte carregada de domínio externo. Cada família puxada do Google Fonts abre uma conexão nova: DNS, TLS, requisição, e só então o texto pinta. Fix: hospedar as fontes localmente, limitar a duas famílias e dois pesos, e usar
font-display: swap. - Script de terceiro sem preconnect. Anúncio, chat, pixel, mapa e vídeo incorporado abrem conexões para domínios que o navegador só descobre quando chega naquela linha do HTML. Foi exatamente aqui que ganhamos nosso segundo: avisar o navegador antes, com preconnect, derrubou o carregamento frio de 3283 ms para 2251 ms.
<!-- No <head>, antes do script de terceiro. Troque os dominios pelos seus. -->
<link rel="preconnect" href="https://dominio-do-terceiro.com" crossorigin>
<link rel="dns-prefetch" href="https://dominio-do-terceiro.com">
<link rel="preload" as="script" crossorigin href="https://dominio-do-terceiro.com/script.js">Cuidado com o exagero: preconnect em dez domínios desperdiça conexão e pode piorar. Use nos dois ou três que realmente aparecem cedo no carregamento.
Causas 15 a 18: as que só aparecem com o cache frio
- JavaScript legado bloqueando o
<head>. No nosso caso eramjquery-migratee o shim do Font Awesome 4 — arquivos que existem para dar compatibilidade com código antigo que talvez você nem use mais. Cada um deles trava a renderização até baixar. Fix: checar se algum plugin realmente depende, e remover da fila por snippet se não depender. - Combinar e adiar JavaScript sem validar página a página. É o recurso mais tentador dos plugins de cache e o que mais quebra site feito com Elementor: menu que não abre, carrossel que some, formulário que não envia. Fix: ligar em um ambiente de teste, validar as páginas de conversão uma a uma e manter uma lista de exclusão para os scripts do construtor.
- Cron do WordPress disparando no carregamento do visitante. O
wp-cronnão é um cron de verdade: ele roda quando alguém abre uma página. Se houver tarefa pesada na fila, o azarado que chegou primeiro paga o tempo dela dentro do próprio TTFB. Fix: desligar owp-cronnowp-config.phpe agendar um cron real no servidor, a cada 5 ou 15 minutos. - Tabela
wp_optionsinchada de autoload. Plugins desinstalados deixam opções para trás, e tudo que está marcado como autoload é lido em toda requisição. É invisível no cache quente e brutal no frio. Fix: medir o peso do autoload e limpar o lixo com cuidado (backup antes, sempre).
-- Quanto a tabela wp_options carrega em TODA requisicao?
SELECT ROUND(SUM(LENGTH(option_value))/1024/1024, 2) AS autoload_mb, COUNT(*) AS itens
FROM wp_options WHERE autoload = 'yes';Acima de 1 MB de autoload já é sinal amarelo; acima de 3 MB, é causa provável do seu TTFB frio.
A ordem que rende mais por hora de trabalho
Dezoito causas não viram tarefa de dezoito dias. Elas se resolvem em quatro blocos, e a ordem importa mais que a quantidade — cada linha abaixo só faz sentido depois da anterior.
| Ordem | O que fazer | Causas | Ganho típico | Risco |
|---|---|---|---|---|
| 1 | Ligar e verificar cache de página | 1 | TTFB frio → quente (no nosso caso, 1247 → 220 ms) | Baixo |
| 2 | Aquecer o cache (crawler/preload) | 2, 3 | Tira o visitante novo do caminho frio | Baixo |
| 3 | Preconnect nos terceiros | 14 | ~1 s no carregamento frio | Baixo |
| 4 | Interruptores do Elementor + limpeza de widget | 6 a 10 | Menos CSS/JS e menos DOM por página | Médio: revalidar layout |
| 5 | Imagens, fontes e lazy load correto | 11 a 13 | LCP e peso | Baixo |
| 6 | Object cache, PHP, autoload, cron | 4, 5, 17, 18 | TTFB frio residual | Médio: exige backup |
| 7 | Combinar/adiar JavaScript | 15, 16 | Variável | Alto: quebra Elementor |
Se você só tiver duas horas neste mês, faça as linhas 1, 2 e 3. Foi o que nos deu a maior parte do resultado, e nenhuma delas exige encostar no layout.
Como saber se o fix funcionou (medição, não sensação)
“Ficou melhor” não é resultado. Resultado é o mesmo par de números que você levantou no começo, agora menor. O roteiro que usamos a cada ciclo:
- Medir frio e quente com os dois comandos do começo deste artigo, sempre deslogado.
- Repetir no mobile — é onde está o visitante do Discover. No nosso caso o mobile chegou a ficar melhor que o desktop (2230 ms contra 2251 ms no frio).
- Conferir que a página não ganhou rolagem horizontal nem erro de console depois da otimização.
- Comparar com dado de campo, não só de laboratório: o CrUX mostra o que os visitantes reais experimentaram, e é ele que o Google usa.
- Registrar o número de cada ciclo. Sem histórico você não sabe se a mudança rendeu ou se o dia estava bom.
Uma honestidade que o assunto exige: variação acontece. Num dos nossos ciclos apareceu um pico isolado de 3895 ms no cache quente, com TTFB de 252 ms — ou seja, o site estava bem e o serviço de terceiro é que demorou. Um único carregamento ruim não é regressão; três medições seguidas são.
Se você quer aprofundar na régua que o Google usa, temos o passo a passo em acelerar WordPress com Core Web Vitals e LiteSpeed e a versão em sete etapas em SEO WordPress: 7 passos para melhorar Core Web Vitals. Para a seleção de plugins que não sabotam a performance, vale a lista dos 10 melhores plugins de WordPress para 2026. E se o sintoma paralelo for de indexação e não de velocidade, o caso do sitemap do Rank Math que não atualiza é o mesmo tipo de armadilha: cache servindo cópia velha sem avisar ninguém.
Para acelerar o diagnóstico e a documentação do que você mudou, o acervo de prompts tem trilhas prontas de otimização de velocidade do site e de métricas de desempenho do site — úteis para transformar medição em relatório que o cliente entende.
Ainda assim, ferramenta não substitui método. Se você trabalha com Elementor todo dia e quer aprender a montar o site já rápido, em vez de consertar depois, é exatamente isso que ensinamos no curso de WordPress do WPRaiz e, para quem precisa de acompanhamento em um projeto específico, na mentoria. Construir leve custa menos que otimizar pesado.
Perguntas frequentes
O Elementor deixa o site lento por natureza?
Não por natureza. Ele gera mais HTML e carrega mais CSS/JS que um tema escrito à mão, e isso tem custo — mas o custo é de dezenas a poucas centenas de milissegundos. O que transforma isso em site arrastado é a combinação com cache ausente ou frio, PHP antigo, imagem no tamanho original e scripts de terceiro sem preconnect. No nosso próprio site, o maior vilão medido não estava no Elementor: era 1 segundo de TTFB no cache frio.
Por que o PageSpeed Insights mostra verde e o site parece lento?
Porque quase sempre você testa a mesma URL duas ou três vezes seguidas e mede o cache quente. O visitante que chega pelo Google ou por um link recém-compartilhado pega a página fria, que no nosso caso respondia o primeiro byte em 1247 ms em vez de 220 ms. Some a isso que o PageSpeed mistura laboratório e dado de campo: o verde do laboratório não é a experiência real dos seus visitantes.
Qual mudança dá mais resultado por hora de trabalho?
Nesta ordem: ligar e verificar o cache de página, aquecer o cache com crawler ou preload, e adicionar preconnect aos domínios de terceiro. As três são de baixo risco, não encostam no layout e, no nosso caso, entregaram a maior parte do ganho — quase 1 segundo só no preconnect.
Vale a pena ligar combinar e adiar JavaScript no plugin de cache?
É o recurso com melhor relação promessa/risco no papel e o pior na prática com Elementor. Ele quebra menu, carrossel e formulário com frequência. Se for ligar, faça em ambiente de teste, valide as páginas de conversão uma a uma e mantenha uma lista de exclusão para os scripts do construtor. Deixe por último: há muito ganho seguro antes dele.
Trocar de hospedagem resolve o Elementor lento?
Resolve a parte que é do servidor — TTFB, versão de PHP, disponibilidade de Redis — e não resolve nada do que está na página: widget pesado, imagem grande, fonte externa, script de terceiro. Antes de migrar, rode a medição de frio e quente: se o frio e o quente forem parecidos e ambos altos, a hospedagem é suspeita real. Se só o frio for alto, o problema é cache e você levaria o problema junto na mudança.
Como saber se foi um plugin específico que deixou o site lento?
Por eliminação, e medindo em vez de sentir. Desative tudo menos o Elementor, meça o frio e o quente, e religue um plugin por vez repetindo a medição. Pacotes de complementos de Elementor são os primeiros suspeitos, porque muitos carregam a biblioteca inteira mesmo quando você usa dois widgets. Faça isso fora do horário de pico, ou em uma cópia de teste.
