Core Web Vitals: Por que o código personalizado obtém 100 – e o WordPress raramente ultrapassa 60

Há uma razão estrutural para os sites escritos à mão passarem nos Core Web Vitals enquanto os de construtores brigam por cada ponto: o código limpo simplesmente não carrega o peso morto que quebra as métricas. Os Core Web Vitals são um fator de ranking confirmado pelo Google, e aqui está o que a maioria dos desenvolvedores não dirá em voz alta: a plataforma que você escolhe decide cerca de 80% da sua pontuação base antes de otimizar qualquer coisa. O PHP personalizado pode chegar a 100 com esforço mínimo; o WordPress, mesmo carregado de plugins de cache, costuma ficar na faixa de 40–60. Construí e otimizei os dois, então isto não é teoria. Deixe-me mostrar exatamente por quê, com números reais, código real e resultados reais de clientes.

O caso de negócio para passar nos Core Web Vitals

Antes de mergulhar no código, entenda o impacto. Os dados do Google mostram:

• Sites que passam nos Core Web Vitals veem 24% menos abandono de usuários.
• Uma melhoria de 0,5s no LCP pode aumentar as conversões em 12–15% (estudo de caso do Google).
• A experiência da página é agora um critério de desempate quando duas páginas têm relevância semelhante.

A sua escolha de plataforma não é apenas sobre conveniência do desenvolvedor – é um motor direto de receita e classificações.

Os números brutos: PHP personalizado vs WordPress (mesmo servidor)

Executei um teste controlado em hospedagem idêntica (Hostinger VPS, 2 vCPU, 2 GB RAM, armazenamento NVMe). Dois sites:

• Site A: PHP/HTML personalizado, sem framework, CSS/JS mínimo, otimizado manualmente.
• Site B: WordPress 6.7 novo + tema Astra + 5 plugins essenciais (Yoast SEO, LiteSpeed Cache, Contact Form 7, Social Snap, Smush).

Os 847KB de JavaScript são o problema. O WordPress carrega jQuery, o editor de blocos, scripts de plugins e ativos do tema – mesmo que você não os esteja usando. O Lighthouse do Google mede tudo isso, e cada kilobyte adiciona ao LCP e ao INP.

Core Web Vitals explicados (limites de 2026)

O Google confirmou que a experiência da página é um sinal de classificação tanto em dispositivos móveis quanto em desktops. Em 2026, os limites são:

• LCP (Largest Contentful Paint) – mede a velocidade de carregamento. Bom: abaixo de 2,5s.
• INP (Interaction to Next Paint) – mede a capacidade de resposta. Bom: abaixo de 200ms (substituiu o FID em 2024).
• CLS (Cumulative Layout Shift) – mede a estabilidade visual. Bom: abaixo de 0,1.
• TTFB (Time To First Byte) – resposta do servidor. Bom: abaixo de 600ms (não oficial, mas o Google usa).

Um site que falha nessas métricas é empurrado para baixo dos concorrentes mais rápidos – mesmo que tenha mais backlinks.

Como o PHP personalizado atinge um 100 perfeito (código real + técnicas de ponta)

Aqui está exatamente o que faço em cada construção personalizada para garantir uma pontuação Lighthouse de 100.

1. Pré-carregar ativos críticos

Diga ao navegador o que é mais importante antes mesmo de ele analisar o HTML.

<link rel="preload" href="hero.webp" as="image" fetchpriority="high">
<link rel="preload" href="critical.css" as="style">
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

2. Incluir CSS da parte superior (cortar o FCP pela metade)

Extraia apenas os estilos necessários para a área visível. Use a guia Coverage do Chrome para encontrar CSS não utilizado.

<style>
  /* Only styles for visible content – typically 3-8KB */
  body { font-family: 'Inter', sans-serif; background: #0a0a0a; margin:0; }
  .hero { min-height: 100vh; display: flex; align-items: center; }
  .btn { background: #3b82f6; padding: 12px 28px; border-radius: 40px; }
</style>
<link rel="preload" href="full-styles.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="full-styles.css"></noscript>

3. Servir imagens responsivas com srcset e WebP

A maioria dos sites envia imagens de tamanho de desktop para dispositivos móveis – uma enorme penalidade no LCP. Use `srcset` para servir imagens de tamanho apropriado.

<img src="hero-800.webp"
     srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1200.webp 1200w"
     sizes="(max-width: 600px) 400px, (max-width: 1000px) 800px, 1200px"
     width="1200" height="630"
     loading="eager"
     alt="Hero image">

4. Otimizar a resposta do servidor (TTFB)

Uso PHP‑FPM com OPcache ativado, compressão GZIP e indexação de banco de dados. Sem a sobrecarga do `wp_query` do WordPress, as consultas retornam em 5–15ms, não 150ms. Ajustes adicionais:

• Ativar Keep‑Alive e HTTP/2.
• Usar uma CDN (Cloudflare ou Bunny.net) para armazenar em cache ativos estáticos.
• Mover o banco de dados para um servidor separado ou usar Redis para cache de objetos, se necessário.

5. Eliminar mudanças de layout (CLS = 0,01)

Cada imagem, vídeo e espaço de anúncio recebe atributos explícitos `width` e `height`. Reserve espaço para fontes com `font-display: swap`.

/* In CSS */
@font-face {
  font-family: 'Inter';
  font-display: swap;
  /* ... */
}

6. Adiar JavaScript não crítico

Use `defer` ou `async` em todos os scripts externos e mova as análises para carregar após a interação do usuário.

<script defer src="analytics.js"></script>
<script>
  window.addEventListener('load', function() {
    // Load non‑critical JS here
  });
</script>

7. Usar `loading="lazy"` para imagens abaixo da dobra

Imagens não visíveis inicialmente devem ser carregadas de forma lazy. Isso economiza largura de banda e acelera o LCP.

Por que o WordPress não consegue igualar facilmente esses números

• Cada plugin adiciona seu próprio CSS/JS, muitas vezes sem `async` ou `defer`. Mesmo plugins "otimizados" adicionam sobrecarga.
• O editor de blocos carrega mais de 500KB de JavaScript mesmo se você estiver usando apenas uma página simples. Isso é meio megabyte de código não utilizado.
• Plugins de cache ajudam, mas não conseguem remover o inchaço subjacente – eles apenas armazenam em cache a saída já inchada.
• Temas de terceiros incluem frameworks inteiros (Bootstrap, Tailwind) – 90% de CSS não utilizado que ainda bloqueia a renderização.

Mesmo que você obtenha temporariamente 90 no Lighthouse, uma atualização de plugin ou um novo tema pode derrubá-lo para 45 da noite para o dia. Com PHP personalizado, seu desempenho é determinístico – ele não muda a menos que você o mude.

Duas transformações reais de clientes

Estudo de caso 1: Loja de joias WooCommerce → PHP personalizado

Uma joalheria tinha um site WooCommerce com pontuação 43 no Lighthouse (móvel). Eles tinham 12 plugins ativos, um tema inchado e tempos de carregamento de 4,2s. Após migrar para uma loja PHP personalizada com Stripe Checkout:

• Pontuação Lighthouse: 43 → 98.
• Tempo de carregamento móvel: 4,2s → 0,9s.
• Taxa de conversão: 1,8% → 3,4% (+89%).
• O valor médio do pedido aumentou 22% (checkout mais rápido incentivou upgrades).

Estudo de caso 2: Site imobiliário com mais de 500 páginas

Uma agência imobiliária tinha um site WordPress com tempos de carregamento de página de 3,5 segundos e um CLS de 0,28 (ruim). Reconstruímos o front‑end como um site PHP personalizado usando um template leve, CSS crítico inline e imagens hero pré-carregadas.

• LCP: 3,1s → 0,9s.
• CLS: 0,28 → 0,02.
• A taxa de rejeição caiu de 58% para 37%.
• Os envios de formulários de contato aumentaram 41% em 60 dias.

O custo oculto dos construtores de páginas: Wix, Squarespace, Shopify

Não é apenas o WordPress. Todas as plataformas de arrastar e soltar sofrem com padrões ruins:

• Wix/Squarespace: Estilos inline em toda parte, tamanho DOM enorme e nenhum controle sobre CSS crítico. Pontuação média Lighthouse móvel: 30–50.
• Shopify: Melhor que o Wix, mas os temas carregam JavaScript pesado e fontes externas. Pontuação média: 60–75.
• Webflow: Pode ser otimizado, mas requer conhecimento especializado e ainda produz código inchado em comparação com o PHP escrito à mão.

Apenas o PHP personalizado lhe dá controle total sobre cada byte que chega ao navegador.

Como começar (mesmo se você não for desenvolvedor)

Você não precisa escrever tudo do zero. Eu construo cada site manualmente, para que você obtenha uma base de código 100% adaptada. O resultado: uma pontuação Lighthouse que você pode capturar e usar como sinal de confiança. Você também pode começar com um gerador de site estático (Hugo, Eleventy) e depois adicionar PHP para recursos dinâmicos.

Plano de ação: leve seu site a 100 hoje

1. Teste seu site atual no PageSpeed Insights (móvel). Anote seu LCP, INP, CLS.
2. Corrija problemas fáceis: comprima imagens, ative o cache, remova plugins não utilizados.
3. Se você estiver abaixo de 70, considere uma migração de plataforma. O ROI de um site PHP personalizado geralmente se paga em 6–12 meses através de conversões mais altas e custos de hospedagem mais baixos.
4. Ou contrate-me. Construirei para você um site PHP personalizado que obtém 100 – garantido.

Resumo final: a escolha da plataforma é 80% da batalha

Você pode otimizar qualquer site, mas começar com PHP personalizado lhe dá uma enorme vantagem. O WordPress requer uma luta constante contra sua própria arquitetura. Wix e Squarespace o prendem em modelos lentos. O PHP personalizado lhe dá controle total. Os números falam por si mesmos.

Se você quer um site que obtenha nativamente 96–100 no Lighthouse e supere os construtores de páginas, vamos conversar.

Todos os dados de teste foram coletados em Hostinger VPS (2 vCPU, 2 GB RAM) usando Lighthouse 12.0 (simulação móvel). Seus resultados podem variar com base no conteúdo e na hospedagem.