Core Web Vitals para sites PHP: como corrigir LCP, INP e CLS

Core Web Vitals para sites PHP não são um tópico apenas de front-end. Uma página PHP lenta pode gastar um segundo apenas produzindo HTML, e nenhuma otimização de imagem recupera isso. Ao mesmo tempo, um servidor muito rápido não ajuda se uma imagem principal de 1,5 MB bloquear a pintura maior. Veja como abordamos ambos os lados em nossos próprios sites PHP (integrono.com executa PHP-FPM por trás de nginx e Cloudflare) e em projetos de clientes.

O que Core Web Vitals mede

• LCP ( Largest Contentful Paint): quando o maior elemento visível (geralmente uma imagem principal ou um bloco de título) é renderizado. Bom é 2,5 segundos ou menos.
• INP ( Interaction to Next Paint): a rapidez com que a página responde visualmente após cliques, toques e pressionamentos de teclas, durante toda a visita. Bom é 200 ms ou menos.
• CLS ( Cumulative Layout Shift): quanto conteúdo salta durante o carregamento. Bom é 0,1 ou menos.

O Google os avalia com base em dados de campo de usuários reais do Chrome, no percentil 75, separadamente para dispositivos móveis e computadores. Isso significa que um modelo lento ou um país lento pode falhar com todo o grupo. Ferramentas de laboratório como Lighthouse são para depuração, não para a pontuação final.

Passo 1. Meça da maneira certa

1. Abra o relatório Core Web Vitals no Google Search Console para ver quais grupos de URL falham e em qual métrica.
2. Verifique PageSpeed Insights para obter um URL de cada grupo com falha. O bloco superior de “dados de campo” é o que conta; o bloco Lighthouse abaixo é um teste de laboratório que explica o porquê.
3. Use o painel Desempenho no Chrome DevTools com desaceleração de CPU 4x e "4G lento" para reproduzir uma experiência móvel típica.
4. Para monitoramento contínuo, colete dados de usuários reais com a biblioteca JavaScript web-vitals e envie-os para suas análises.

<script type="module">
  import {onLCP, onINP, onCLS} from 'https://unpkg.com/web-vitals@4?module';
  const send = (m) => navigator.sendBeacon('/vitals', JSON.stringify({
    name: m.name, value: m.value, id: m.id, url: location.pathname
  }));
  onLCP(send); onINP(send); onCLS(send);
</script>

Etapa 2. Corrija primeiro o tempo de resposta do servidor ( TTFB)

LCP inclui o tempo antes da chegada do primeiro byte. Se o seu HTML levar 800 ms para ser gerado, você já gastou um terço do orçamento. Em sites PHP as alavancas usuais são:

• Habilite OPcache e certifique-se de que ele seja grande o suficiente para conter todos os scripts. Sem ele, o PHP recompila arquivos em cada solicitação.
• Ajuste PHP-FPM. Poucos trabalhadores enfileiram solicitações, muitos esgotam a memória. Observe a página de status PHP-FPM para "fila de escuta" e "máximo de filhos alcançados".
• Armazene páginas inteiras em cache para visitantes anônimos (nginx fastcgi_cache, um cache de resposta Laravel ou regras de cache Cloudflare) e armazene fragmentos em cache ou resultados de consulta com Redis.
• Corrija consultas lentas. Ative o log de consulta lenta, procure padrões N+1 e adicione índices. Uma página que executa 120 consultas é lenta, independentemente da versão do PHP.
• Mantenha o PHP atualizado. As versões mais recentes do PHP são mais rápidas e usam menos memória.

# php.ini (production)
opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0   ; reload php-fpm on each deploy

# php-fpm pool
pm = dynamic
pm.max_children = 20
pm.start_servers = 4
pm.min_spare_servers = 2
pm.max_spare_servers = 6
pm.max_requests = 500

Defina pm.max_children da memória real: divida a memória que você pode fornecer ao PHP pelo tamanho médio de um processo de trabalho (verifique com ps). Com validate_timestamps=0 lembre-se de recarregar PHP-FPM após cada implantação, caso contrário o código antigo permanecerá na memória.

No nível do servidor web, habilite HTTP/2 ou HTTP/3, Brotli ou gzip e cabeçalhos de cache de longa duração para arquivos estáticos:

location ~* \.(?:css|js|webp|avif|jpg|png|svg|woff2)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}
gzip on;
gzip_types text/css application/javascript application/json image/svg+xml;

Use nomes de arquivos com versão ou uma consulta ?v= com base no horário de modificação do arquivo para que "imutável" nunca sirva ativos obsoletos.

Etapa 3. Corrija o elemento LCP

Encontre o elemento LCP no PageSpeed Insights ou no painel DevTools Performance. Na maioria das páginas de conteúdo, é uma imagem principal. Então:

• Não carregue com preguiça. loading="lazy" na imagem LCP atrasa. Use fetchpriority="high" em vez disso.
• Sirva no tamanho certo. Uma imagem de 2.400 px para um slot de 900 px desperdiça bytes. Use srcset e sizes.
• Utilize WebP ou AVIF. A economia típica é de 30 a 60 por cento em relação ao JPEG de qualidade semelhante.
• Evite correntes. Uma imagem definida via background CSS ou injetada por JavaScript é descoberta tarde. Coloque-o no HTML como um <img>.
• Pré-conecte ou auto-hospede origens de terceiros das quais o LCP depende (fontes, CDN de imagem).

<img src="/images/hero-1200.webp"
     srcset="/images/hero-640.webp 640w, /images/hero-1200.webp 1200w"
     sizes="(max-width: 1040px) 92vw, 960px"
     width="1200" height="630"
     alt="Descriptive alt text"
     decoding="async" fetchpriority="high">

Este é o padrão que o artigo aborda neste blog: dois tamanhos WebP, dimensões explícitas e alta prioridade de busca para o herói.

Etapa 4. Remover mudanças de layout ( CLS)

• Sempre defina width e height (ou aspect-ratio em CSS) em imagens, vídeos e iframes para que o navegador reserve espaço.
• Reserve espaço para banners, avisos de cookies e anúncios. Insira-os em um contêiner com altura mínima fixa em vez de empurrar o conteúdo para baixo após o carregamento.
• Fontes: use font-display: swap ou optional, pré-carregue o arquivo de fonte principal e crie um subconjunto dele. Escolha uma fonte substituta com métricas semelhantes.
• Não injete conteúdo acima do conteúdo existente, a menos que o usuário o tenha acionado.
• Anime com transform e opacity, não com propriedades que alteram o layout (top, height).

Etapa 5. Melhore INP: menos JavaScript no thread principal

INP é a métrica mais nova e aquela que os desenvolvedores de PHP negligenciam, porque o servidor não a influencia diretamente. As causas estão no navegador: tarefas longas de pacotes grandes, scripts pesados de terceiros (análises, widgets de chat, gerenciadores de tags) e manipuladores que fazem muito trabalho de forma síncrona.

• Audite scripts de terceiros. Retire o que ninguém usa, carregue o resto com defer ou após a primeira interação.
• Divida tarefas longas. Divida o trabalho em partes com requestIdleCallback, setTimeout ou a Scheduler API; mover computação pesada para um Web Worker.
• Mantenha o DOM pequeno. Milhares de nós tornam cada atualização lenta.
• Evite layouts síncronos forçados em loops (leitura e gravação de propriedades de layout alternadamente).
• Mostre feedback imediato (um estado pressionado ou girador) antes de iniciar o trabalho lento.

Etapa 6. Proteja-o em seu processo de implantação

O desempenho regride silenciosamente: uma nova tag, um herói mais pesado, uma consulta extra na página inicial. Adicione Lighthouse CI ou uma verificação agendada da API PageSpeed para seus cinco modelos mais importantes, defina orçamentos ( LCP, tamanho total do JS, peso da imagem) e alerte quando eles forem excedidos. Compare TTFB antes e depois de cada lançamento; se saltar, a causa quase sempre é uma consulta ou um cache que não atinge mais.

Uma ordem de trabalho realista

1. Meça os dados do campo e identifique grupos de URLs com falha.
2. Habilite OPcache, revise as configurações PHP-FPM, adicione cache de página inteira para tráfego anônimo.
3. Corrija imagens principais: formato, tamanho, prioridade, dimensões.
4. Reserve espaço para tudo que carrega tarde.
5. Reduza e adie JavaScript; remover terceiros não utilizados.
6. Meça novamente após 28 dias, pois os dados de campo são uma janela contínua.

Espere que as melhorias apareçam gradualmente no Search Console: o relatório usa aproximadamente os últimos 28 dias de dados, portanto, uma correção enviada hoje só fica totalmente visível após cerca de um mês.

Como podemos ajudar

Fazemos trabalho de performance em projetos PHP e Laravel como parte de um compromisso técnico de SEO e como ajuste único: cache, consultas, imagens e correções de front-end enviadas em código. Se você quer saber quais das mudanças acima renderiam no seu site, marque uma consulta ou uma análise do servidor. Para uma lista de verificação mais ampla sobre rastreamento e indexação, leia nossa lista de verificação técnica de auditoria de SEO.