Artigo
19 de Novembro de 2025 | FRT Digital
Core Web Vitals — Estratégias Avançadas de Otimização de Performance
Além do básico — como diagnosticar e resolver problemas reais de LCP, INP e CLS em aplicações Next.js e React complexas
Leia mais
Além do básico — como diagnosticar e resolver problemas reais de LCP, INP e CLS em aplicações Next.js e React complexas
19 de Novembro de 2025 | FRT Digital
Core Web Vitals são as métricas de performance que o Google usa para avaliar a experiência de página — e que afetam diretamente o ranqueamento de busca desde 2021. LCP (Largest Contentful Paint), INP (Interaction to Next Paint) e CLS (Cumulative Layout Shift) são os três indicadores atuais. Este artigo vai além das otimizações básicas para examinar diagnóstico em produção, casos complexos de regressão e estratégias específicas para aplicações React e Next.js que já implementaram as otimizações óbvias.
LCP: indo além da otimização de imagem
LCP mede o tempo até que o maior elemento visível na viewport seja renderizado. Para a maioria dos sites, esse elemento é uma imagem hero ou uma imagem de produto. As otimizações básicas — formato WebP, lazy loading, CDN — são necessárias mas frequentemente insuficientes.
Resource hints para imagens críticas: O browser só descobre a imagem LCP quando o HTML é parseado e os estilos são aplicados. Para imagens que são sempre o elemento LCP, adicionar `` no `
` instrui o browser a fazer download antes mesmo de começar a renderizar. Em Next.js, a prop `priority` no componente `Eliminando a cadeia de redirecionamentos de imagem: Em muitas aplicações, a URL final da imagem passa por um ou mais redirecionamentos (CDN redirect, resize service redirect, auth redirect). Cada redirect adiciona uma round-trip de latência. Ferramentas de diagnóstico como WebPageTest mostram essa cadeia explicitamente. A solução é sempre servir a URL final diretamente.
Server-side rendering do elemento LCP: Se o elemento LCP é renderizado client-side (via JavaScript), o LCP só é marcado após a hydration — o que pode ser centenas de milissegundos depois do HTML inicial. Server Components ou SSR garantem que o elemento esteja no HTML inicial.
TTFB (Time to First Byte) como root cause de LCP ruim: Um TTFB alto contamina todas as outras métricas. TTFB elevado pode indicar servidor lento, banco de dados sem índice adequado, ou ausência de cache de response. New Relic, Datadog e o próprio Web Vitals report do Google Search Console ajudam a distinguir problemas de servidor de problemas de client.
INP: a métrica mais difícil de otimizar
INP (que substituiu FID em março de 2024) mede a responsividade da página a interações do usuário — especificamente o tempo entre o evento de input e a próxima pintada na tela. Um INP acima de 200ms é considerado ruim.
O desafio do INP é que ele mede o pior percentil 75 de todas as interações na sessão — não apenas o carregamento inicial. Qualquer código JavaScript executado em resposta a um clique, toque ou digitação que bloqueie a main thread por tempo significativo pode causar INP ruim.
Profiling de INP com Chrome DevTools: No Performance panel, filtre por "interactions" para ver quais eventos têm maior duração. O breakdown mostra Input Delay (tempo até o handler começar), Processing Time (tempo do handler) e Presentation Delay (tempo até pintar). Cada componente tem causas e soluções diferentes.
Quebrando trabalho longo com scheduler.yield(): Em interações que precisam processar grandes volumes de dados (filtros em tabelas longas, re-render de listas complexas), usar `scheduler.yield()` ou `setTimeout(fn, 0)` quebra o trabalho em chunks que permitem ao browser intercalar renders e manter a interface responsiva.
Deferindo work não-crítico: Código de analytics, tracking e inicialização de terceiros executado em resposta a interações deve ser diferido. `requestIdleCallback` é ideal para work que pode esperar o browser estar ocioso.
Virtualization em listas longas: Renderizar 500 itens de uma lista no DOM e re-renderizar todos em resposta a um filtro é a causa mais comum de INP ruim em aplicações de dados. TanStack Virtual e react-window implementam virtualização eficiente.
CLS: layout shifts invisíveis que afetam o score
CLS mede a instabilidade visual — quanto o conteúdo "pula" durante o carregamento. A causa mais comum e mais simples é imagens sem dimensões explícitas: o browser não reserva espaço para a imagem até que ela carregue, causando shift.
Mas CLS de causas menos óbvias é frequentemente responsável por scores ruins mesmo depois das otimizações básicas:
Fontes web e FOUT/FOIT: Quando a fonte web carrega e substitui a fonte fallback, o texto pode mudar de tamanho e causar shift. A propriedade CSS `size-adjust` no `@font-face` da fonte fallback permite ajustar o tamanho para corresponder à métrica da fonte web, minimizando o shift na transição.
Banners de cookies e notificações: Elementos que aparecem após o carregamento inicial e empurram o conteúdo para baixo causam CLS. A solução é reservar o espaço para esses elementos no layout inicial (via height fixo) ou exibi-los em overlay sem afetar o fluxo do documento.
Ads e iframes: Conteúdo de terceiros inserido dinâmicamente após o carregamento é uma das principais fontes de CLS em publishers. Sempre reserve espaço com dimensões fixas para o container de ads.
Monitoramento de CWV em produção
Lab data (Lighthouse, WebPageTest) mede em condições controladas. Field data (CrUX — Chrome User Experience Report) mede o que usuários reais experimentam. Os dois frequentemente divergem — e o Google usa field data para ranqueamento.
Para coletar field data granular, a biblioteca `web-vitals` da Google permite instrumentar cada métrica e enviar para seu analytics:
```typescript import { onLCP, onINP, onCLS } from 'web-vitals';
function sendToAnalytics({ name, value, id }) { window.gtag('event', name, { event_category: 'Web Vitals', value: Math.round(name === 'CLS' ? value * 1000 : value), event_label: id, non_interaction: true, }); }
onLCP(sendToAnalytics); onINP(sendToAnalytics); onCLS(sendToAnalytics); ```
Com isso, você consegue segmentar por página, dispositivo, tipo de conexão e percentil — transformando CWV de uma métrica de laboratório em um sinal de monitoramento contínuo de produção.
Performance não é uma tarefa que se conclui — é um atributo que precisa ser monitorado e defendido continuamente contra a entropia natural de um produto que cresce.
Artigo
Core Web Vitals — Estratégias Avançadas de Otimização de Performance
19 de Novembro de 2025 | FRT Digital
Leia também
Artigo
Product Discovery — Validando Hipóteses Antes de Codar
08 de Outubro de 2025

