Performance e Core Web Vitals em sites Next.js + WordPress

TL;DR

Core Web Vitals são as três métricas de performance que o Google usa como sinal de ranqueamento e que sites WordPress tradicionais costumam falhar. Em sites Next.js + WordPress, performance vem de cinco decisões: next/image com priority no hero, formato WebP only (não AVIF), 3 device sizes ao invés de 6, ISR de 5 minutos servindo HTML do edge, e lazy loading nativo no conteúdo Gutenberg. Aplicar essas decisões consistentemente coloca LCP abaixo de 1,5 segundo e CLS abaixo de 0,1 em projetos do nosso portfólio.

Os três Core Web Vitals que importam

Em 2026, o Google avalia três métricas centrais de experiência do usuário, todas medidas a partir do que o visitante real percebe. Entendê-las é pré-requisito para otimizar com método em vez de chutar.

LCP (Largest Contentful Paint): tempo até o maior elemento visível da viewport aparecer. Em sites institucionais, geralmente é a imagem do hero ou um heading grande. Meta: abaixo de 2,5 segundos. Acima de 4 segundos é classificado como “ruim”.

CLS (Cumulative Layout Shift): mede o quanto a página “pula” durante o carregamento, quando elementos chegam atrasados e empurram o conteúdo já visível. Meta: abaixo de 0,1. Acima de 0,25 é “ruim”.

INP (Interaction to Next Paint): mede o tempo de resposta da página a qualquer interação do usuário (clique, toque, tecla). Substituiu o FID em março de 2024. Meta: abaixo de 200ms. Acima de 500ms é “ruim”.

Os três precisam estar verdes para o site ser classificado como “good” no Google PageSpeed Insights. Falhar em uma só métrica derruba a classificação geral.

next/image vs <img>: onde cada um faz sentido

O Next.js oferece um componente <Image> que automatiza otimização: gera múltiplos tamanhos via srcset, serve formato WebP automaticamente, lazy loading por padrão, dimensões obrigatórias para evitar CLS. É a escolha certa para imagens do layout do site (hero, cards, logos).

O conteúdo do post WordPress é diferente. Ele já vem com srcset embutido (o WordPress gera múltiplos tamanhos no upload) e renderiza com tag <img> tradicional dentro do content.rendered. Tentar substituir essas <img> por componentes Next.js após renderização adiciona complexidade sem ganho real.

O modelo que adotamos:

Checklist: onde usar cada um

• <Image> com priority: hero da homepage, hero das páginas internas, primeira imagem de listagens above-the-fold

• <Image> sem priority (lazy by default): cards de listagem, logos de parceiros, imagens em sections below-the-fold

• <img> nativa do content.rendered: imagens dentro do corpo do post, aproveitando o srcset e loading="lazy" que o WordPress já adiciona

Erro mais comum: esquecer priority no hero. Sem ela, o <Image> vira lazy por padrão e o LCP dispara, porque a imagem mais importante da página passa a competir com tudo o resto pelo download.

WebP only: por que não AVIF (no nosso contexto)

O Next.js suporta dois formatos modernos de imagem: WebP e AVIF. AVIF tem compressão melhor (arquivos 20-30% menores), mas tempo de geração 2-3 vezes maior e suporte ainda inferior em alguns navegadores antigos.

Em sites institucionais com tráfego de até 100 mil visitas mensais, o ganho de bytes não compensa o overhead de geração. O modelo que entrega melhor relação custo-benefício é WebP only:

// next.config.ts
images: {
formats: ["image/webp"],
deviceSizes: [640, 1080, 1920],
imageSizes: [128, 320],
minimumCacheTTL: 2592000, // 30 dias
}

O deviceSizes com 3 tamanhos (mobile, tablet, desktop) cobre 95% dos casos de uso. O default do Next.js usa 6 tamanhos, gerando 6 variações de cada imagem, o que dobra tempo de build e armazenamento sem ganho perceptível.

Em sites de e-commerce ou portais com tráfego acima de 500 mil visitas mensais, vale reativar AVIF para reduzir bandwidth global. Para o resto, WebP only é o sweet spot.

ISR + edge: HTML estático em milissegundos

A peça que mais contribui para LCP baixo em sites Next.js + WordPress é o cache de edge. Quando uma página é gerada via ISR, o HTML resultante fica armazenado em todos os pontos de presença da CDN. Requisições subsequentes recebem esse HTML diretamente do nó mais próximo, sem passar pelo servidor da aplicação.

O resultado prático: o tempo até o primeiro byte (TTFB) cai de 500-800ms (típico de WordPress tradicional) para 30-80ms (típico de edge cache). Esse ganho se traduz diretamente em LCP, porque o navegador começa a renderizar mais cedo.

Em projetos do nosso portfólio, vimos TTFB cair de 720ms (WordPress tradicional em hospedagem dedicada) para 45ms (Next.js + WordPress headless servido do edge da Vercel). É uma redução de 16x, no maior gargalo da experiência inicial.

O Next.js gerencia o cache automaticamente. O único cuidado: garantir que páginas dinâmicas tenham revalidate definido no fetch da REST API, não cache: 'no-store' (que desativa o cache e força SSR a cada request).

Lazy loading no conteúdo Gutenberg

Posts longos com muitas imagens podem prejudicar LCP se todas as imagens carregarem ao mesmo tempo. O WordPress moderno já adiciona loading="lazy" em imagens fora da primeira viewport por padrão (desde a versão 5.5). É um ganho gratuito que vem junto com o content.rendered.

Para garantir que o atributo está presente, basta verificar o HTML retornado pela REST API. Se o seu WordPress estiver atualizado e usando o tema padrão para gerar HTML, o atributo já está lá. Se não estiver, vale instalar um plugin pequeno como “Lazy Load Images” ou habilitar via filtro PHP.

Vídeos embutidos (YouTube, Vimeo) costumam ser o vilão escondido. Cada iframe carrega scripts externos pesados, mesmo que o vídeo não esteja visível. Em vídeos abaixo do fold, vale substituir o iframe por um placeholder leve (imagem do thumbnail + botão de play) que só carrega o iframe ao clicar.

Bundle size: o que ainda dói em Next 16

O bundle JavaScript inicial impacta INP e Time to Interactive. Em sites Next.js, três fontes comuns de bloat:

Bibliotecas pesadas no client: Framer Motion (~80KB) costuma ser exagero para animações simples. IntersectionObserver + CSS transitions resolve a maioria dos casos com 80KB a menos no bundle. Em projetos do nosso portfólio, removemos Framer Motion sempre que viável.

Componentes não tree-shakeáveis: bibliotecas que exportam tudo do index.js sem permitir import nominal podem trazer código morto para o bundle. lodash é o exemplo clássico: import { debounce } from 'lodash' traz a biblioteca inteira. Use lodash.debounce ou implemente o helper sem dependência.

Server Components vs Client Components: qualquer componente marcado como "use client" e seus filhos viram bundle. O padrão certo é manter o máximo possível como Server Component e usar Client Components em pequenas ilhas (forms, dropdowns, animações específicas).

Medindo de verdade: PageSpeed, CrUX e RUM

Otimizar sem medir é chute. Três fontes de dado complementares para acompanhar Core Web Vitals:

Google PageSpeed Insights: roda Lighthouse em uma URL específica em condições simuladas. Útil para diagnóstico inicial e para validar correções pontuais. Não reflete o que o usuário real vê.

CrUX (Chrome User Experience Report): dados reais de visitantes que usam Chrome com sync. Aparece no Search Console e no PageSpeed. Reflete a média móvel dos últimos 28 dias. É o que o Google realmente usa para ranqueamento. Demora a refletir mudanças (28 dias de janela).

RUM (Real User Monitoring): coleta métricas direto dos visitantes em tempo real. Ferramentas como Vercel Analytics, Sentry Performance ou Cloudflare Web Analytics expõem CWV ao vivo, segmentado por página, dispositivo, geografia. É o que dá feedback rápido sobre regressões.

Checklist: rotina de monitoramento

• PageSpeed Insights nas 5 páginas mais importantes do site, mensalmente

• CrUX no Search Console, semanalmente, para captura de regressões largas

• RUM em tempo real para investigação de incidentes pontuais

• Alerta automatizado se LCP médio passar de 2,5s ou CLS de 0,1 em qualquer ferramenta

Próximos passos

Performance em sites Next.js + WordPress é resultado de decisões pequenas aplicadas consistentemente, não de hacks pontuais. Os próximos e anteriores artigos da série completam o quadro: SEO programático no Next.js 16 mostra como traduzir performance em ranqueamento, e a arquitetura completa explica como ISR e cache se conectam.

Se você ainda está avaliando o modelo headless, leia o artigo de visão estratégica. Para entender como o conteúdo do WordPress é renderizado no front-end, consulte o artigo sobre blocos Gutenberg.

Quer auditar a performance do seu site atual e planejar otimizações? Fale com a Virtus Design. Conheça também a nossa ferramenta gratuita de auditoria SEO e o portfólio completo de serviços.