CORE WEB VITALS EM 2026

O trabalho de desempenho em 2026 se divide em dois grupos. O grupo reativo ajusta páginas individuais quando caem abaixo de um limite. O grupo estrutural constrói desempenho na escolha do framework, no design system, no pipeline de deployment e na disciplina de conteúdo, de modo que desempenho é o resultado padrão do trabalho, não uma otimização que acontece depois. Todos os sites que vi ter sucesso a longo prazo estão no grupo estrutural.

Este guia é a visão estrutural. Números concretos de sites que lancei, os checks reais que executo, os erros mais custosos que cometi, e as partes do conselho convencional que se mostraram erradas na prática. Dados de campo do CrUX sempre vencem dados de laboratório do PageSpeed Insights, então a maioria dos números abaixo vem de usuários reais no percentil 75.

LCP (Largest Contentful Paint)

O tempo até o maior elemento acima da dobra renderizar. Alvo: menos de 2,5 segundos no percentil 75. O Core Web Vital mais citado, frequentemente o mais fácil de corrigir uma vez que você identifica o elemento LCP corretamente. A maioria dos sites tem uma imagem ou um bloco de texto hero como elemento LCP; a correção é quase sempre pré-carregar a imagem, dimensioná-la corretamente e garantir que nenhum JavaScript bloqueie a renderização.

CLS (Cumulative Layout Shift)

O quanto o conteúdo da página se desloca inesperadamente durante o carregamento. Alvo: menos de 0,1. A métrica mais frequentemente quebrada por imagens lazy-loaded sem largura e altura explícitas, por anúncios injetados após a primeira renderização, ou por web fonts trocando com métricas diferentes da fallback. Solucionável na maioria dos casos sendo disciplinado sobre dimensões explícitas em todo elemento visual acima da dobra.

INP (Interaction to Next Paint)

O tempo de interação mais lento experimentado durante a vida útil da página. Alvo: menos de 200ms. Substituiu FID em março de 2024. A métrica CWV mais difícil de se vencer, porque expõe o atrito real do usuário com JavaScript em tarefas de longa execução. Sites com JavaScript client pesado quase sempre enfrentam dificuldades aqui. A correção é enviar menos JavaScript, dividir tarefas longas em pedaços menores e usar requestIdleCallback para trabalho não urgente.

TTFB (Time to First Byte)

Tempo de resposta do servidor antes que qualquer renderização possa começar. Alvo: menos de 600ms. Não é oficialmente um Core Web Vital mas limita todas as outras métricas. Sites renderizados estaticamente em uma CDN atingem tipicamente 50 a 150ms. WordPress em hospedagem compartilhada atinge 800ms a 2,5s em cache frio. A decisão de hospedagem é a maior alavanca de TTFB.

Dados de laboratório dizem o que uma máquina em um local mediu em um momento sob condições controladas. Dados de campo dizem o que usuários reais experimentaram em escala. Os dois divergem significativamente na maioria dos sites, e dados de campo é o que Google usa para sinais de ranking. Otimize para dados de campo primeiro, dados de laboratório segundo.

Onde ler dados de campo

Search Console > relatório Core Web Vitals. Dataset CrUX no BigQuery se você quer dados brutos em nível de evento. PageSpeed Insights > seção Field Data (quando existem dados de usuários reais suficientes para a URL). Calibre, SpeedCurve e Treo fornecem dashboards enriquecidos em cima do CrUX para usuários pagos. Ferramentas RUM (real user monitoring) como Vercel Analytics ou Cloudflare Web Analytics adicionam granularidade adicional.

Onde ler dados de lab

PageSpeed Insights > seção Lab Data. Lighthouse no Chrome DevTools. WebPageTest para análise granular de waterfall. Útil para diagnosticar o porquê por trás de uma regressão de métrica de campo, não para medi-la.

O fluxo diagnóstico que executo

Regressão de métrica de campo no Search Console. Identifique o padrão de URL afetado. Execute testes de lab via WebPageTest em três locais para reproduzir. Inspecione o waterfall para encontrar a requisição ofensora. Corrija. Aguarde 28 dias para os dados de campo do CrUX se atualizarem. Confirme o corretivo.

Números reais de LCP que vi no percentil 75 dos dados de campo nas plataformas que mais implemento:

Astro renderizado estaticamente no Netlify ou Cloudflare Pages

LCP típico de 0,6 a 1,0 segundos. Lighthouse 100 em todos os quatro métricas é o resultado padrão. JavaScript inicial abaixo de 30KB. Nível mais difícil de vencer para sites de conteúdo.

Next.js renderizado estaticamente (App Router com RSC, modo SSG)

LCP de 1,0 a 1,5 segundos. JavaScript inicial de 80 a 150KB dependendo de quantos componentes client são enviados. Lighthouse 90+ é alcançável mas requer otimização deliberada.

ISR ou SSR Next.js

LCP de 1,5 a 2,5 segundos dependendo da taxa de acerto do cache e do tempo de resposta da origem. Falhas de cache frio ficam em 3 a 5 segundos. Tecnologia excelente com uma curva de custo real e variância de performance real.

WordPress em Kinsta ou WP Engine mais Cloudflare

LCP típico de 1,8 a 2,8 segundos. É alcançável limpar os limites do CWV com disciplina. Sites que rodo nessa stack passam no CWV no percentil 75 consistentemente após a passada de otimização.

WordPress em hospedagem compartilhada

LCP de 3,5 segundos ou pior. Evite para qualquer site onde performance faz parte do escopo.

Imagens são o elemento de LCP em aproximadamente 70% das páginas de marketing. Disciplina em imagens é a alavanca de performance com maior efeito que conheço.

Formato e compressão

WebP com qualidade 82 é o ponto ideal entre qualidade visual e tamanho de arquivo. AVIF é menor, mas a codificação é mais lenta e o suporte do navegador tem lacunas sutis. Ignore JPEG e PNG para qualquer imagem que não seja original de fonte-verdade. WebP com q=82 tipicamente produz arquivos 70 a 90% menores que o PNG de origem sem perda perceptível.

Redimensione para dimensões reais de renderização

Um JPEG 4K renderizado com 1200 pixels de largura é 90% de desperdício de banda. Sempre redimensione para a maior dimensão em que a imagem será renderizada, mais uma versão 2x ou 3x para telas de alta densidade. Sharp faz isso em aproximadamente cinco linhas de código em qualquer pipeline de build Node.js.

FAL hero pipeline

Geramos imagens hero via FAL flux-pro/v1.1-ultra e Imagen 4 diretamente do pipeline de auto-blog. As imagens geradas são JPEGs de 600KB a 1.5MB em 1200x675. Fazer upload direto para Supabase Storage significa que cada página carrega ~1MB só do hero. Passamos por sharp(buf).resize({width:1600, fit:"inside"}).webp({quality:82}).toBuffer() antes do upload para storage. Reduz o tamanho do arquivo 90% sem perda perceptível. Vimos uma economia de 50MB em todo o site em 53 imagens hero em um único site Seahawk após aplicar este pipeline. Use cacheControl: 31536000 no upload para storage também.

Width e height explícitos em cada img

Os navegadores reservam espaço antes da imagem carregar apenas se width e height estão presentes no HTML. Sem eles, há deslocamentos de layout conforme as imagens carregam e CLS aumenta. Componentes Astro e Next.js Image lidam com isso automaticamente; tags img puras precisam manualmente.

LCP image preload

A imagem hero acima da dobra deve ser pré-carregada com link rel="preload" as="image" no head. Economiza tipicamente 100 a 400ms. A mudança de uma única linha com maior impacto disponível na maioria dos sites de marketing.

JavaScript é o maior passivo de performance na maioria dos sites modernos. O orçamento com o qual trabalho em 2026:

JavaScript inicial abaixo de 100KB em sites de conteúdo

Abaixo de 100KB o framework, o site e qualquer pixel de analytics ou marketing combinados ainda fazem parse e executam rápido o suficiente em um dispositivo mobile de médio alcance. Acima de 100KB o custo aparece em INP e TTI, muitas vezes invisível para o desenvolvedor de desktop testando em um laptop rápido.

Adie tudo que não está acima da dobra

Analytics, social pixels, chat widgets, scripts de A/B testing. Nenhum desses precisa bloquear o first paint. Use o atributo defer ou carregue na interação do usuário. A melhoria em CWV é frequentemente dramática, a perda de engajamento costuma ser zero.

Evite componentes client pesados acima da dobra

Um hero carousel que requer React + framer-motion + 30KB de código de suporte para renderizar o primeiro frame é um passivo de performance. Renderize o primeiro slide como HTML estático e hidrate o carousel apenas quando o usuário estiver prestes a interagir.

Audite scripts de terceiros trimestralmente

Scripts de marketing se acumulam silenciosamente. Um site com uma tag de analytics em 2020 tem oito scripts em 2026 se ninguém auditar. Execute uma verificação trimestral via Lighthouse ou webpagetest, identifique o que ainda está valendo seu lugar e remova qualquer coisa que não esteja.

CSS crítico inserido, resto carregado posteriormente

O CSS necessário para renderizar acima da dobra deve ser inserido no head. O resto pode carregar de forma assíncrona. Astro e Next.js lidam com isso automaticamente através do escopo de CSS; sites manuais precisam de uma etapa de extração de critical-css no pipeline de build.

Auto-hospede fontes e use font-display: swap

Fontes web carregadas do Google Fonts adicionam típicamente 100 a 300ms. Auto-hospedá-las na mesma origem do site elimina a busca DNS. font-display: swap renderiza texto alternativo imediatamente enquanto a fonte web carrega, eliminando FOIT (flash of invisible text). Fontes variáveis onde suportadas entregam múltiplos pesos de um único arquivo.

Faça subset de fontes para os idiomas que você realmente serve

Um subset de fonte Latin ocupa 30 a 60KB. O arquivo completo multi-idioma costuma ter 250KB+. Fazer subset é uma mudança de uma linha na maioria dos pipelines de build e economiza largura de banda significativa em cada carregamento de página.

A hospedagem e a camada edge importam mais do que a maioria das equipes reconhece. O conselho não óbvio:

Cloudflare na frente da origem sempre

Independentemente se sua origem é Vercel, Netlify, AWS ou um host WordPress gerenciado, colocar Cloudflare na frente melhora a latência global, absorve tráfego de bots e adiciona cache que a origem teria que servir de outro modo. A camada gratuita é suficiente para a maioria dos sites; as camadas pagas adicionam observabilidade e recursos de segurança.

Renderização estática é a maior alavanca de performance

HTML pré-renderizado servido de nós edge de CDN atinge TTFB abaixo de 100ms globalmente. Sem salto para a origem, sem consulta a banco de dados, sem render de template. Se seu conteúdo não precisa estritamente ser dinâmico, renderize-o estaticamente.

Edge functions para a superfície dinâmica

Quando você realmente precisa de comportamento dinâmico (autenticação, personalização, A/B), edge functions em Cloudflare Workers ou Vercel Edge Functions executam mais perto do usuário do que servidores de origem. A latência cai dramaticamente sem o ônus operacional de rodar infraestrutura.

Fique atento ao custo de ISR no Vercel em escala

Incremental Static Regeneration é uma tecnologia excelente com uma curva de custo real. Atingimos um mês de faturamento ISR de múltiplos milhões de eventos em Deluxe Astrology em março de 2026. A solução foi uma regra explícita de "dois merges em produção por semana", já que cada merge dispara aproximadamente seis milhões de eventos de escrita ISR na escala de 91 mil páginas. Planeje-se para isso se estiver rodando ISR em um site grande.

Antes de declarar qualquer novo site ou template pronto para lançamento, executo este checklist. É intencionalmente curto. Checklists longos nunca são usados.

1. A imagem hero é pré-carregada com link rel preload como image. 2. Imagens acima da dobra têm width e height explícitos. 3. Formato WebP, qualidade 82, redimensionadas para dimensões de render. 4. CSS crítico inline, o resto diferido. 5. Web fonts auto-hospedadas com font-display: swap. 6. JavaScript inicial abaixo de 100KB. 7. Scripts de analytics e marketing diferidos. 8. Colunas CSS Grid usam minmax(0, 1fr) e não 1fr para prevenir overflow em conteúdo longo. 9. Renderização estática onde o conteúdo permite. 10. Cloudflare em frente da origem. 11. Dados de campo medidos semanalmente via Search Console. 12. Linter de SEO em tempo de build falha o build em regressões.

Sites que lançam com todos os doze no lugar raramente têm problemas de CWV. Sites que pulam três ou quatro eventualmente falham no 75º percentil e o time se vê na correria para consertar depois que o Google já percebeu.

Nem todo site precisa atingir Lighthouse 100. O enquadramento honesto para a pergunta "quanto trabalho de performance é suficiente":

Sites com menos de 10 mil visitantes mensais sem dependência comercial de rankings de busca: atinja os limites de CWV no percentil 75 e pare. Otimização adicional produz retornos decrescentes. Dedique o tempo a conteúdo ou produto em vez disso.

Sites com tráfego pago onde taxa de conversão importa: a cada 100ms de LCP custa aproximadamente 1 a 4% de conversões em benchmarks médios. Otimização além dos limites de CWV normalmente se paga em escala. Faça as contas, priorize de acordo.

Sites onde Lighthouse score faz parte do briefing da marca: atinja Lighthouse 100 e trate qualquer regressão como um bug. O trabalho de otimização se acumula porque o time não deixará regressões ir para produção.

Sites com times editoriais que não manterão disciplina de otimização: escolha o framework que entrega performance por padrão (Astro, Next.js renderizado estaticamente, WordPress headless com hosting gerenciado) e aceite a restrição. Otimização manual de performance que o time não consegue manter vale menos que um padrão ligeiramente menos ótimo que sobrevive.

Performance em 2026 é uma postura estrutural: escolha de framework, escolha de hosting, disciplina de pipeline de imagens, orçamento de JavaScript, disciplina de CSS e fontes, edge caching, e a checklist de CWV aplicada a cada lançamento. Sites que incorporam isso cedo ganham um piso de performance que se acumula. Sites que adicionam isso depois gastam mais por menos.

Você não precisa de cada linha deste guia no primeiro dia. Você precisa saber qual alavanca você ainda não acionou, e acionar a próxima antes que os dados de campo digam que já era tarde demais.

Se você quer um audit de Core Web Vitals no seu site específico, rodamos eles na Seahawk Media a partir de 2.500 USD. O audit produz análise de dados de campo, remediação priorizada, e um perfil de métrica alvo que você pode rastrear ao longo do tempo.