LCP
Largest Contentful Paint
Mede quanto tempo o maior elemento visível demora para aparecer. Até 2,5 segundos é considerado bom; acima de 4 segundos, ruim.
serviçossite wordpress rápido
Deixe seu site WordPress rápido sem trocar tudo por impulso
Site WordPress lento raramente tem uma causa única. Normalmente é uma combinação de servidor, tema, builder, imagens, JavaScript e plugins. Eu meço cada camada, encontro o gargalo dominante e corrijo na ordem que traz mais resultado.
Em abril de 2026, cerca de 49% das origens WordPress incluídas no Chrome UX Report passaram nas três métricas de Core Web Vitals, segundo uma análise do Search Engine Journal baseada em CrUX e HTTP Archive. No mesmo recorte, Duda, Wix, Shopify, Astro e Drupal tiveram percentuais maiores.
O dado mostra uma diferença entre as amostras observadas. Não prova que o WordPress, isoladamente, causou a reprovação. Hospedagem, tema, plugins, equipe e tipo de site também variam.
Minha experiência prática é que uma instalação enxuta e bem mantida pode passar com folga.
medição
Eu comparo dados de usuários reais com testes controlados e mostro quanto do atraso vem do servidor, do navegador, das imagens e do banco.
Fale comigoaprovação em core web vitals — abril de 2026
Percentual de origens presentes no conjunto analisado que passaram nas três métricas, segundo Search Engine Journal. Não é uma comparação controlada entre sites idênticos.
As três métricas do Google
Os limites abaixo vêm da documentação dos Core Web Vitals, resumida também no guia da Kinsta.
INP
Interaction to Next Paint
Mede a resposta após uma interação. JavaScript em excesso, tarefas longas e DOM grande costumam piorar o resultado.
CLS
Cumulative Layout Shift
Mede deslocamentos inesperados do layout. Até 0,1 é bom; acima de 0,25, ruim.
O Google usa dados de campo quando existe amostra suficiente. A nota do PageSpeed Insights é um teste de laboratório e serve para diagnóstico. É possível ter nota alta no teste e reprovar com usuários reais.
causas
Por que o site está lento
01
Servidor demora para responder
TTFB alto consome parte do tempo antes de o navegador receber o HTML. Primeiro confirmo se o atraso é constante, regional ou restrito a páginas dinâmicas. Depois comparo hospedagem, cache e custo de processamento.
02
PHP antigo
Uma versão suportada pode melhorar desempenho e segurança, mas a migração precisa passar por teste de compatibilidade. Não atualizo produção no escuro.
03
JavaScript demais
Plugins podem carregar scripts em páginas onde sua função nem aparece. Eu identifico o que bloqueia interação, removo duplicidade e condiciono o carregamento por página quando é seguro.
04
Page builder além do necessário
Builder dá autonomia, mas pode gerar HTML e CSS extras. O critério é medir se esse custo prejudica a meta do site e se migrar pagaria a diferença.
05
Imagens sem tratamento
Arquivo maior do que a exibição, ausência de WebP ou AVIF, dimensões não declaradas e prioridade errada da imagem principal afetam LCP e CLS.
06
Cache incompleto
Cache de página ajuda muito, mas sites dinâmicos podem precisar também de cache de objeto, regras por fragmento e cabeçalhos corretos na CDN.
WooCommerce pede outro diagnóstico
Loja virtual tem carrinho, checkout, sessões, pedidos e extensões que não existem num site institucional. A equipe do WooCommerce documentou otimizações relevantes no produto, incluindo redução de 51,9% em algumas telas de pedidos, queda de 221 KB para 60,2 KB de JavaScript no painel e ganhos de até 95% em operações específicas.
Esses resultados vêm de testes e funções determinados. Não são promessa de ganho igual em qualquer loja.
Avaliar HPOS
O High Performance Order Storage guarda pedidos em tabelas próprias. Pode melhorar escala e administração, mas extensões precisam ser verificadas antes da ativação.
Preferir blocos atuais quando fizer sentido
Blocos de produto recebem manutenção ativa e podem substituir shortcodes antigos em partes da loja.
Tratar carrinho e checkout como páginas críticas
São áreas dinâmicas, muitas vezes fora do cache. O teste deve incluir frete, pagamento, cupom, estoque e dispositivos móveis.
Revisar extensões
Cada extensão pode acrescentar consultas, scripts e risco. A decisão de remover precisa considerar a função comercial, não apenas a velocidade.
otimização de performance
Meço, encontro o gargalo e implemento. Se o servidor for o limite, explico isso antes de vender ajustes de front-end.
A ordem que costuma funcionar
01
Medir
CrUX e Search Console mostram usuários reais. O laboratório ajuda a reproduzir e identificar a causa. Registro uma linha de base antes da alteração.
02
Corrigir infraestrutura
Servidor, versão de PHP, compressão, protocolo e distribuição geográfica entram antes de ajustes finos quando os dados apontam para essa camada.
03
Cortar o que não entrega valor
Removo plugins sem uso, scripts duplicados e fontes desnecessárias. Nem todo byte merece esforço; priorizo o que afeta a rota crítica.
04
Tratar imagens
Dimensão correta, formato adequado, largura e altura declaradas, carregamento tardio abaixo da primeira tela e prioridade na imagem principal.
05
Configurar cache em camadas
Página, objeto e borda têm funções diferentes. A configuração precisa respeitar login, carrinho, personalização e atualização de conteúdo.
06
Reduzir trabalho no navegador
Adio código não crítico, removo o que não é usado e quebro tarefas longas que prejudicam o INP.
07
Medir novamente
O laboratório responde rápido. Dados de campo usam uma janela móvel de 28 dias, portanto a confirmação exige acompanhamento.
Quando WordPress pode não ser a melhor resposta
Se o site distribui muito conteúdo, depende de integrações ou tem performance comprovadamente ligada à conversão, uma arquitetura headless pode oferecer mais controle. O WordPress continua como CMS e o Next.js entrega o front-end.
Isso aumenta custo, número de serviços e dependência técnica. Para muitos sites institucionais, otimizar a instalação atual é suficiente.
Eu comparo os dois caminhos antes de propor uma migração.
o trabalho
Como eu trabalho
01
Diagnóstico de campo e laboratório
Separo a experiência dos usuários reais do teste controlado e identifico servidor, front-end, banco ou conteúdo como causas.
02
Plano por impacto e esforço
Cada item recebe prioridade, dependência, risco e forma de validação.
03
Implementação
Faço as alterações em homologação e publico com backup e rollback preparados.
04
Verificação
Comparo antes e depois com a mesma metodologia e acompanho a janela de dados de campo.
Perguntas frequentes
Quanto tempo leva para deixar um WordPress rápido?
Algumas correções aparecem no laboratório no mesmo dia. Mudança de tema, builder ou hospedagem leva mais tempo. A confirmação em dados de campo usa uma janela de 28 dias.
Um plugin de cache resolve?
Pode resolver parte do problema. Não corrige sozinho servidor lento, JavaScript pesado, consulta ruim ou imagem excessiva.
Preciso trocar de hospedagem?
Somente se a medição mostrar que o servidor limita o resultado e a otimização local não compensa. Troca de hospedagem tem custo e risco, então comparo antes.
Page builder deixa o site lento?
Ele costuma adicionar marcação e estilos, mas o efeito varia. Para muitos sites o custo é aceitável. Em loja ou operação dependente de conversão móvel, pode virar gargalo.
Site rápido melhora o ranqueamento?
Core Web Vitals participa dos sinais do Google, com peso menor que relevância e autoridade. O ganho comercial mais direto costuma estar na experiência e na conversão.
Vale migrar para Next.js headless?
Vale quando o ganho esperado paga a complexidade e existe manutenção técnica. Não recomendo migração apenas para buscar uma nota maior.
Fontes
Search Engine Journal: Core Web Vitals por plataformaWooCommerce: melhorias de performance em escalaWooCommerce: High Performance Order StorageKinsta: guia de Core Web VitalsWP Tavern: aprovação de sites WordPress nos Core Web VitalsWP Tavern: Gutenberg e page buildersWordPress Core: benchmarks de performance
diagnóstico de performance
Quanto seu site pode ganhar?
Analiso o site e mostro o que limita o resultado, o ganho provável e o custo da correção. Se o investimento não se pagar, essa também é uma conclusão válida.
Fale comigo