Elementor vs Claude Code: a humilhação de performance que eu vejo no PageSpeed
Você compra o Elementor, paga plugin de imagem, de cache e de SEO, e o site tira 40, 50, 60 no PageSpeed do Google. Eu peço o mesmo site pra uma inteligência artificial em HTML estático e bato quase 100. Aqui eu conto de onde vem essa diferença, com a visão de quem vende o site, dá manutenção nele e paga a conta.
🎧 PREFERE OUVIR? · 13 min · Podcast Em Produção
Este artigo também é um episódio do podcast Josimar JMV | Em Produção — o mesmo vídeo, só o áudio, normalizado pra fone.
Gravei esses 13 minutos no canal @josimarjmv em 16 de junho de 2026, direto, sem edição no meio. Assista e leia junto. Aqui embaixo eu conto a mesma coisa por escrito e ponho o que eu fui conferir depois na documentação do Google: Core Web Vitals, as faixas de nota do PageSpeed e a política contra conteúdo em escala.
um site em HTML estático, feito com Claude Code ou com qualquer outra inteligência artificial de desenvolvimento, humilha um WordPress com Elementor em performance. Com Elementor e uma pilha de plugin você gasta uns R$ 2.000 pra chegar em nota 60, 70 no PageSpeed do Google. O mesmo site, reproduzido em HTML puro, bate quase 100. O motivo é camada: sai o banco de dados, sai o cache, sai o código cheio de div dentro de div, e o servidor só entrega um arquivo pronto. A meta que eu uso é pelo menos 90.
De onde eu falo
Elementor contra Claude Code é uma briga injusta. Davi contra Golias. E tem muita gente que ainda não sabe o poder de uma IA de desenvolvimento, ou só está vendo esse monte de papagaio de pirata repetindo coisa sem saber o motivo real.
Vou dar minha carteirada antes. Eu atuo como engenheiro de infraestrutura no dia a dia (não tenho CREA, antes que alguém me xingue). Coordeno servidores no Brasil e nos Estados Unidos, um data center de distribuição de vídeo, e sou CEO de uma empresa de tecnologia. Então a minha visão não é só técnica. É a de quem paga a conta: de quem precisa vender o site, dar manutenção, cuidar dele e fazer dinheiro com ele.
Eu falo de Claude Code porque é o que está na moda. Vale pra Codex, GPT ou a IA que você quiser, paga ou gratuita. E falo aqui de quem compra o Elementor e paga a licença bonitinho. Quem compra Elementor craqueado no Mercado Livre pra fazer site pros outros é outro departamento, eu nem entro nessa. Se você não leva o seu negócio a sério, o mundo te devolve isso.
A conta começa na imagem de 2 MB
Vamos pegar o caso da agência. Você tem um monte de site, foi lá e comprou o Elementor. É rapidinho de fazer: arrasta, solta, pronto.
Aí o sistema deixa subir uma imagem de 2 MB. A pessoa que subiu não tem a maldade de que precisa otimizar. Sobe dez. O site fica naquele load, load, load. Qual é a saída que todo mundo acha? Instalar um plugin pra otimizar imagem, às vezes gratuito, às vezes pago. Começou mais um plugin.
Depois vem o SEO. Você paga outro plugin pra conseguir indexar no Google. E a busca mudou: antes era só palavra-chave, hoje é busca semântica, por linguagem natural. Elementor antigo e plugin antigo de SEO não se adequaram a isso, e eu vi uma reviravolta no resultado de busca de muita empresa. Quem não pegou essa onda um, dois anos atrás caiu dramaticamente de posição. Eu conto essa parte com calma em sem site em 2026, a IA não vai recomendar a sua empresa.
Artigo em lote não é a saída
Não adianta pagar plugin de SEO e contratar uma dessas IAs de "auto SEO" pra gerar artigo em lote. É coisa errada, e o Google anda punindo. Criar um domínio hoje e botar 5.000 artigos do dia pra noite é pedir pra ser punido. É meio óbvio.
Fui conferir como o Google escreve isso. Nas políticas de spam da Pesquisa existe um item chamado abuso de conteúdo em escala: muitas páginas geradas com o objetivo principal de manipular a classificação, e não de ajudar o usuário. O primeiro exemplo da lista é usar IA generativa pra gerar muitas páginas sem agregar valor.
Pausa e faz esse teste no seu site
Por que eu chamo de lixo o código que o Elementor deixa? Não acredita em mim. Faz o teste agora, se você tem um site em WordPress com Elementor:
- Abre o site, clica com o botão direito e aperta F12. Olha a quantidade de requisição que a página faz pra carregar.
- Manda exibir o código-fonte e tenta ler aquilo.
- Põe o endereço no PageSpeed Insights do Google e anota a nota.
Dá pra ver até sem entender de código. É um tanto de div dentro de div dentro de div, uma bagunça, uma coisa horrorosa. Você fica abismado.
O Google tem número pra isso. A auditoria de tamanho do DOM do Lighthouse, que é o motor por trás do PageSpeed, avisa quando o corpo da página passa de 800 nós e acusa erro quando passa de 1.400. Esse é o limite que a ferramenta usa. O número do seu site, só o seu teste diz.
Engenharia básica: cada camada tira performance
Qualquer pessoa que entende de engenharia, de qualquer tipo, conhece a premissa: quanto mais camada você põe, mais complexo fica e menos performance tem. Prédio é assim: quanto mais alto, mais estrutura precisa. Carro é assim. O câmbio PowerShift da Ford é o exemplo que me vem à cabeça: puseram camada em cima de camada em vez de fazer o básico, e deu o problema que deu.
WordPress com Elementor é a mesma coisa. O visitante acessa o seu site e o Elementor, comilão de banco de dados, tem que ir lá no banco. Então você precisa de um plugin de cache pra ele ir menos ao banco. Um plugin pra cache dinâmico, um pra cache estático, um pra SEO, um pra isso, um pra aquilo.
R$ 2.000 de plugin pra chegar em nota 60
No final das contas você pega esse site e coloca no PageSpeed. Isso é básico. Você que faz site pra vender, e você que é empreendedor e consome site, precisa pôr o endereço lá e ver a nota.
"A nota do meu site tá 40, tá 30, tá 50, tá 60." Você gastou R$ 2.000 de plugin pra chegar em 60, 70. E ainda assim não chega nem perto de bater 90. Isso é um problema.
Por que essa nota importa? Porque o Google joga lá pra baixo site lento. Ele privilegia muito a experiência do usuário: clicou, abriu, já são uns pontinhos a mais pro seu site aparecer nas primeiras colocações.
O que o Google mede de verdade
Aqui eu faço um ajuste fino, porque fui ler a documentação antes de escrever. O que o Google declara que usa são as Core Web Vitals, não a nota de 0 a 100. A página sobre experiência na página diz com todas as letras que as Core Web Vitals são usadas pelos sistemas de classificação. E as três métricas são medidas na experiência real de quem acessa:
| Métrica | O que mede | Meta do Google |
|---|---|---|
| LCP | Quando o conteúdo principal aparece | Até 2,5 segundos |
| INP | Quanto a página demora pra responder ao toque ou clique | Menos de 200 milissegundos |
| CLS | Quanto o layout pula enquanto carrega | Menos de 0,1 |
A mesma documentação avisa que resultado bom nessas ferramentas não garante o topo da busca, e que perseguir pontuação perfeita só por SEO talvez não seja o melhor caminho. Eu concordo. Performance é uma das várias coisas que o Google olha. Idade do domínio, conteúdo, isso tudo é assunto de SEO pra outro momento.
Então eu uso a nota como termômetro. A documentação do Lighthouse separa assim: de 90 a 100 é bom, de 50 a 89 precisa de melhorias, de 0 a 49 é ruim. O site de nota 40, 50, 60 está na faixa laranja ou na vermelha. E site que vai mal no teste dificilmente entrega experiência boa pra quem clica.
O WP Rocket é esperto, e não resolve 100%
Existe um plugin que eu usei por muito tempo, o WP Rocket. É relativamente inteligente. Ele pega o site, gera o HTML estático dele e guarda numa página interna pra servir como cache. É esperto da parte deles. É uma forma de contornar o problema todo do WordPress.
Mas não funciona 100%. Eu não vou entrar nos motivos técnicos. Se funcionasse, o site batia 80, 90 com facilidade no PageSpeed, e não era o que eu via.
E é um plugin caro quando você tem muitos sites. Pra um site só também não é barato. Conferi a tabela oficial em 9 de outubro de 2026: US$ 59,95 por ano pra 1 site, US$ 119,95 pra 3 e US$ 299,95 por ano pra 50 sites. É mais uma licença em dólar na sua planilha, todo ano.
Repara no que o plugin faz pra acelerar: ele transforma a página em arquivo estático. O que resolve, ali, é o arquivo estático. Guarda isso.
O mesmo site em HTML puro: quase 100
Agora pega uma inteligência artificial e pede pra ela fazer o mesmo site. Manda abrir o site tal e reproduzir pra você em HTML puro, HTML cru. Você vai bater quase 100 na nota. Por isso eu chamo de humilhação. É uma humilhação absurda.
Não quer HTML na mão? Quer um build em JavaScript? Pode usar um Astro, um Vite, alguma coisa assim. O build cospe o arquivo estático no final, e é isso que vai pro servidor.
Quando você cruza uma página estática com um WordPress qualquer é, sem brincadeira, botar uma Ferrari pra correr contra um Fusca. Você tira todas as camadas: banco de dados, cache, aquele tanto de plugin, aquele código horroroso. Sobra um código limpo, bonito. Dá gosto de ver, a gente fica até emocionado.
Uma nota honesta sobre os números. O 40 a 70 do WordPress com Elementor e o quase 100 do estático são o que eu vejo no meu dia a dia. Não é benchmark de laboratório, e eu não testei todo tema e toda hospedagem do mundo. Por isso o teste da seção de cima é seu: põe o seu site no PageSpeed e olha a sua nota.
"Mas fazer todas as páginas em HTML?"
É, cara. Sim.
Pensa no que é um CMS. Por que vieram o WordPress, o Elementor, os builders? Só existe um motivo pro WordPress ter pegado entre dono de empresa e colaborador de empresa: facilidade de produzir layout e conteúdo. Pronto. Eu já fiz site em Joomla. Era mais restrito visualmente, mas era bom, super estável. Qualquer framework existe pra facilitar. O WordPress bombou, com aquela loja gigantesca de tema e plugin, pela facilidade de fazer conteúdo e template.
Quando você tem uma coisa mais fácil pra produzir conteúdo e página em massa, essa necessidade se perde. É o que eu descrevo em a queda do WordPress: o site estático voltou, sem CMS nenhum. Existem exceções, casos em que o WordPress ainda faz sentido, e eu não trato todas aqui. Performance não é mais uma delas.
Ferramenta de terceiro tem manutenção, e o preço não é seu
Eu não falo isso de fora. Já usei WPBakery. Já fizemos template próprio aqui. Lá no comecinho, antes de mexer com WordPress, a gente fez um builder nosso, e depois transferiu tudo pra WordPress. E aí tinha que dar manutenção.
Eu já tive um site invadido que era Elementor. Segurança hoje é o mundo, e isso é assunto pra outra conversa.
Quando você decide usar qualquer ferramenta externa, lembra do pacote inteiro:
- ela precisa de manutenção;
- ela tem atualização;
- ela pode sair do ar;
- ela tem um preço que pode subir. Dizem que pode baixar também. Eu nunca vi nada baixar de preço.
Antes de montar o site, aliás, tem uma decisão que vem primeiro. Eu explico em como eu escolho o nome do site antes de criar com IA.
Fazer o HTML não é vender site
Hoje é muito fácil fazer site, e tem muita gente fazendo. Mas é muito diferente mandar a IA fazer um HTML e deixar na sua máquina, e aprender o fluxo completo que você pode vender. Uma coisa é fazer um negócio pra você, que não tem risco nenhum. Outra é fazer pra um cliente. São coisas completamente diferentes.
Nota de cronologia. Quando eu gravei, em junho de 2026, eu estava juntando gente num grupo de WhatsApp pra fazer um aulão ao vivo e subir um pipeline inteiro na frente de todo mundo. Essa aula aconteceu: a primeira turma foi em 15 de agosto de 2026. O que existe hoje está na página da Imersão de Sites.
Fecho com o mesmo recado da gravação. A preocupação enorme que você tem que ter com o seu site é a velocidade de carregamento. PageSpeed do Google batendo pelo menos 90, com Claude Code, GPT ou a IA que você quiser. Nessa questão de velocidade, não dá nem pra comparar com WordPress.
Discorda? Concorda? Tem um caso parecido? Aqui não tem caixa de comentário de propósito: segunda-feira, ao meio-dia, eu faço live no canal e a gente conversa sobre isso ao vivo — sem corte, como sempre.
Ver as lives no canal @josimarjmv →Perguntas frequentes
Site feito com IA em HTML estático é mesmo mais rápido que WordPress com Elementor?
Na minha experiência, é covardia. Quando eu pego uma inteligência artificial e peço o mesmo site em HTML puro, eu bato quase 100 no PageSpeed do Google. Com WordPress e Elementor você gasta uns R$ 2.000 em plugin pra chegar em 60, 70. O motivo é camada: o estático não tem banco de dados, não tem plugin de cache, não tem aquele tanto de div dentro de div. O servidor só entrega um arquivo pronto.
Qual nota eu devo buscar no PageSpeed do Google?
Eu busco pelo menos 90. Fui conferir na documentação do Lighthouse, que é o motor do PageSpeed: de 90 a 100 a nota fica verde e é considerada boa, de 50 a 89 precisa de melhorias e de 0 a 49 é ruim. Então o site de nota 40, 50, 60 que eu vejo toda hora em WordPress com construtor está na faixa laranja ou na vermelha.
A nota do PageSpeed é fator de ranqueamento no Google?
A nota em si, não. O que o Google declara que os sistemas de classificação usam são as Core Web Vitals, medidas na experiência real de quem acessa: carregamento, resposta e estabilidade visual. A mesma documentação avisa que resultado bom nessas ferramentas não garante o topo da busca. Eu uso a nota como termômetro: site que tira 40 no teste dificilmente entrega uma experiência boa pra quem clica.
Por que o WordPress com Elementor fica lento?
Porque é camada em cima de camada. O visitante chega, o WordPress vai ao banco de dados, o Elementor monta a página com um monte de div dentro de div, e você empilha plugin pra compensar: um pra otimizar imagem, um pra cache dinâmico, um pra cache estático, um pra SEO. Em qualquer engenharia, quanto mais camada você põe, mais complexo fica e menos performance sobra.
WP Rocket resolve a lentidão do WordPress?
Ajuda, e não resolve 100%. Eu usei o WP Rocket por muito tempo. É um plugin relativamente inteligente: ele pega o site, gera o HTML estático e serve aquilo como cache. É uma forma esperta de contornar o problema do WordPress. Só que, se funcionasse 100%, o site batia 80, 90 com facilidade no PageSpeed, e não é o que eu via. E é mais uma licença pra pagar e manter.
Então eu devo abandonar o WordPress?
Não é isso que eu estou dizendo. O WordPress pegou por um motivo só: facilidade de produzir layout e conteúdo. Quando aparece uma coisa mais fácil pra produzir conteúdo em massa, que é a IA, essa necessidade cai muito. Mas existe caso em que o WordPress ainda faz sentido, e eu não trato todos aqui. O que eu digo é que performance, hoje, não é mais um deles.
Preciso do Claude Code ou serve outra IA?
Serve qualquer uma. Eu falo do Claude Code porque é o que está na moda, mas vale Codex, GPT ou a inteligência artificial de desenvolvimento que você quiser, paga ou gratuita. O ganho não vem da marca da IA. Vem de sair um arquivo estático limpo no final, em HTML puro ou num build com Astro ou Vite.
Fazer o HTML com IA já é saber vender site?
Não. Mandar a IA fazer um HTML e deixar na sua máquina é uma coisa. Aprender o fluxo completo, colocar em produção e vender pra cliente é outra, completamente diferente. Quando é pra você, não tem risco nenhum. Quando é pra um cliente, tem manutenção, tem segurança e tem alguém pagando por aquilo.
Baseado na gravação do canal @josimarjmv publicada em 16/06/2026 (13min12s), com transcrição própria das legendas do próprio vídeo.
O que veio da gravação e o que é apuração minha, com as fontes
Da gravação: a minha atuação em infraestrutura e como CEO; o caso da agência que compra o Elementor; a imagem de 2 MB e a pilha de plugin de imagem, cache e SEO; a mudança da busca por palavra-chave pra busca semântica; o domínio novo com 5.000 artigos do dia pra noite; o teste do F12 e do código-fonte; a premissa das camadas, com o exemplo do prédio e do câmbio PowerShift; as notas 30 a 70 no PageSpeed e os R$ 2.000 de plugin; o uso do WP Rocket, do WPBakery, do Joomla, de template e de builder próprios; o site invadido que era Elementor; o quase 100 do site reproduzido em HTML puro; Astro e Vite; a comparação da Ferrari com o Fusca; a meta de pelo menos 90; e a diferença entre fazer um HTML e vender site pra cliente. As notas são da minha experiência, não de um benchmark controlado. Os números 52 e 98 da capa são a arte do vídeo, não uma medição.
Apuração minha (09/10/2026): o uso das Core Web Vitals pelos sistemas de classificação, e o aviso de que nota boa não garante o topo da busca, estão em Como entender a experiência na página, Google Search Central. As metas de LCP (2,5 segundos), INP (200 milissegundos) e CLS (0,1) estão em Core Web Vitals e os resultados da Pesquisa Google. As faixas de nota (0 a 49, 50 a 89, 90 a 100) estão em Pontuação de desempenho do Lighthouse. Os limites de 800 e 1.400 nós estão na auditoria de tamanho do DOM do Lighthouse. O abuso de conteúdo em escala está nas políticas de spam da Pesquisa Google. Os preços do WP Rocket estão na tabela oficial, e a geração de arquivos HTML estáticos como cache está na página de recursos do plugin. A data da primeira turma da Imersão de Sites é a que está publicada neste site.