Core Web Vitals no Next.js: LCP, INP e CLS na prática

O site parece rápido no seu computador, mas o cliente diz que o menu demora e a página “pula” no celular. Melhorar Core Web Vitals no Next.js começa por transformar essas percepções em problemas observáveis. Reduzir uma nota ruim sem identificar a experiência afetada costuma produzir otimizações pouco relevantes.

Eu separo três perguntas: quando o conteúdo principal aparece, quando a interface responde e quanto o layout se movimenta inesperadamente? Cada uma aponta para um tipo diferente de investigação.

O que medir nos Core Web Vitals no Next.js

A avaliação considera o percentil 75, separando experiências mobile e desktop. Não é a média dos três indicadores nem a melhor execução de um teste. Definições oficiais de Web Vitals.

Na prática, eu relacionaria um LCP alto à demora para entender a proposta da página, um INP alto à dúvida sobre se o clique funcionou e um CLS alto à perda da posição de leitura ou de um alvo de toque. Essas relações ajudam a priorizar pelo impacto na tarefa.

Primeiro: laboratório e usuários reais respondem perguntas diferentes

Um teste controlado ajuda a reproduzir um problema. Dados de campo mostram experiências reais, com diversidade de aparelhos, redes e interações. Uma URL com pouco tráfego pode não ter dados próprios no CrUX; confira quando a ferramenta apresenta dados da origem inteira. Guia de diagnóstico de LCP.

Meu roteiro é registrar rota, dispositivo, elemento afetado e interação. “O site está lento” vira, por exemplo: “na página do serviço, o conteúdo principal aparece tarde em acesso mobile sem cache”. Essa frase é pequena, mas elimina muitas tentativas aleatórias.

Não compararia uma medição em desenvolvimento com uma em produção como se fossem equivalentes. Também registraria se o teste usou cache aquecido e quais scripts externos estavam ativos.

LCP: descubra o que está atrasando o conteúdo principal

O atraso pode estar na resposta inicial do servidor, na descoberta do recurso, no download ou na etapa até renderizá-lo. Comprimir uma imagem ajuda quando o download é o gargalo; não resolve sozinho uma imagem descoberta apenas depois de uma cadeia de JavaScript. Etapas de otimização de LCP.

Um hero com espaço e prioridade definidos

No Next.js 16, Image oferece preload; a documentação desaconselha combiná-lo indiscriminadamente com outras estratégias de prioridade. O exemplo pressupõe que essa é a imagem principal, conhecida e visível no primeiro viewport. Referência de Image.

import Image from 'next/image';

type ServiceHeroProps = {
  imageSrc: string;
  imageAlt: string;
};

export function ServiceHero({ imageSrc, imageAlt }: ServiceHeroProps) {
  return (
    <section className="mx-auto max-w-6xl px-6">
      <h1>Um site que facilita conhecer sua empresa</h1>
      <div className="relative aspect-[16/9] overflow-hidden rounded-2xl">
        <Image
          src={imageSrc}
          alt={imageAlt}
          fill
          sizes="(min-width: 1152px) 1104px, calc(100vw - 48px)"
          preload
          className="object-cover"
        />
      </div>
    </section>
  );
}

Passe uma imagem local existente ou configure as origens remotas permitidas. O contêiner reserva a proporção; sizes descreve a largura de apresentação. Eu revisaria esse valor junto do layout, porque uma mudança de grid pode tornar a indicação antiga inadequada.

Para imagens abaixo da dobra, manteria carregamento tardio. Dar prioridade a todos os cards cria competição e deixa de expressar qual recurso realmente importa primeiro.

INP: investigue o intervalo entre intenção e resposta

INP envolve atraso de entrada, processamento e apresentação do próximo frame. Trabalho longo na thread principal pode interferir mesmo quando não está dentro do handler do botão. Guia de otimização de INP.

Num filtro de catálogo, eu gravaria a interação no painel Performance e procuraria o trabalho mais caro. As soluções dependem do diagnóstico:

• Se o conjunto é pequeno, simplificar a transformação pode bastar.
• Se há muitos elementos, paginação ou virtualização podem reduzir a renderização.
• Se o cálculo é pesado e independente do DOM, avaliaria um Worker.
• Se o custo vem de terceiros, investigaria sua necessidade e momento de execução.

Um spinner pode melhorar a comunicação, mas não reduz o custo do cálculo. Minha preferência é responder ao clique imediatamente e evitar bloquear a interface com trabalho que pode ser dividido ou adiado.

CLS: reserve o espaço antes do recurso chegar

Imagens sem dimensões, conteúdo inserido acima do que já foi renderizado e mudanças de fontes podem produzir deslocamentos. Nem toda alteração de layout conta da mesma forma na métrica; ainda assim, estabilidade visual merece avaliação além da pontuação. Guia de CLS.

Num card, eu reservaria a proporção da imagem e daria ao skeleton uma estrutura próxima do conteúdo final. Para uma barra de aviso, definiria conscientemente se ela ocupa espaço desde o início ou se é uma camada sobreposta com controles acessíveis.

Animações de entrada não deveriam empurrar o botão que a pessoa está prestes a tocar. Na revisão de design, esse é um problema de previsibilidade, mesmo quando uma exceção da métrica impede que aquele movimento entre na pontuação.

Quando eu usaria isso em um projeto real?

Em uma landing page, começaria pelo carregamento da proposta principal e do CTA. Em um painel, daria atenção especial às interações recorrentes. Num blog, observaria leitura, imagens e elementos inseridos depois do carregamento.

Eu definiria uma melhoria por vez, repetiria a medição nas mesmas condições e acompanharia os dados de campo depois da publicação. Sem esse ciclo, é fácil atribuir uma mudança a uma otimização que não foi a causa.

Performance também precisa conviver com acessibilidade e SEO. Um texto renderizado cedo, legível e semanticamente organizado é mais útil do que um hero visualmente impressionante que esconde a mensagem até terminar uma sequência.

Erros comuns

Perseguir apenas a nota do Lighthouse

Ela ajuda a diagnosticar, mas não substitui a experiência de campo. Eu guardaria traces e indicadores da rota para saber o que realmente mudou.

Usar lazy loading na imagem principal

Atrasar a descoberta de um recurso que a pessoa precisa ver imediatamente pode contrariar o objetivo do primeiro carregamento. Confirme qual é o elemento LCP antes de definir prioridade.

Tratar SSR como garantia de performance

HTML no servidor pode ajudar, mas ainda existem consultas, imagens, estilos e trabalho de hidratação. A sigla não descreve o custo completo da página.

Conclusão

Melhorar Core Web Vitals no Next.js é um processo de diagnóstico orientado à experiência. Escolha uma rota, reproduza uma dificuldade e elimine o gargalo com evidência. A melhor otimização é a que torna uma tarefa mais rápida e previsível para quem usa o site.