Core Web Vitals em 2026: O Que Mudou e Como Otimizar

O que são Core Web Vitals em 2026

Core Web Vitals são um conjunto de métricas definidas pelo Google para avaliar a experiência real do usuário em uma página web. Desde março de 2024, o conjunto oficial passou a ser composto por três métricas: LCP (Largest Contentful Paint), INP (Interaction to Next Paint) e CLS (Cumulative Layout Shift). Cada uma mede uma dimensão diferente da experiência: velocidade de carregamento, responsividade a interações e estabilidade visual.

A mudança mais relevante dos últimos anos foi a substituição do FID (First Input Delay) pelo INP (Interaction to Next Paint) em março de 2024. O FID média apenas a primeira interação do usuário e ignorava tudo o que acontecia depois. O INP corrigiu essa limitação ao medir todas as interações durante o ciclo de vida da página, oferecendo uma visão muito mais realista da responsividade.

Na prática, sites que passavam facilmente no FID começaram a falhar no INP. Na minha experiência com mais de 500 projetos, estimo que 35% dos sites que tinham FID "bom" passaram a ter INP "precisa melhorar" ou "ruim" após a transição. Isso acontece porque o FID era uma métrica generosa demais: média apenas o delay da primeira interação, sem considerar o tempo de processamento nem o tempo até a próxima renderização.

Os limiares atuais para cada métrica são:

• LCP (Largest Contentful Paint): Bom até 2.5s, precisa melhorar entre 2.5s e 4s, ruim acima de 4s
• INP (Interaction to Next Paint): Bom até 200ms, precisa melhorar entre 200ms e 500ms, ruim acima de 500ms
• CLS (Cumulative Layout Shift): Bom até 0.1, precisa melhorar entre 0.1 e 0.25, ruim acima de 0.25

Essas métricas não são apenas tecnicalidades, elas impactam diretamente o ranking no Google. O Page Experience Update integrou Core Web Vitals como sinal de classificação, e em 2026 esse peso so aumentou, especialmente em mercados competitivos onde dezenas de páginas concorrem pela mesma keyword com conteúdo de qualidade similar.

INP: a nova métrica que substituiu o FID

INP (Interaction to Next Paint) mede o tempo entre uma interação do usuário (clique, toque ou pressionamento de tecla) e o momento em que o navegador consegue renderizar a próxima frame visual como resultado dessa interação. Diferente do FID, que média apenas o input delay da primeira interação, o INP captura três componentes de cada interação:

1. Input Delay: o tempo entre a interação do usuário e o início do processamento do event handler. Acontece quando a main thread está ocupada com outras tarefas.
2. Processing Time: o tempo que os event handlers JavaScript levam para executar. Callbacks pesados, manipulações de DOM complexas e cálculos intensivos inflam esse valor.
3. Presentation Delay: o tempo entre o final do processamento e a próxima frame renderizada pelo navegador. Layout recalculations, paint e compositing acontecem aqui.

O INP reporta o pior valor observado durante toda a sessão do usuário (com uma tolerância estatística para outliers em sessões com muitas interações). Isso significa que uma única interação lenta (como um clique em um botão de filtro que trava por 800ms) pode comprometer o INP inteiro da página.

Como medir o INP

O INP e uma métrica de campo, ou seja, e medida com dados reais de usuários (RUM (Real User Monitoring)). No entanto, existem ferramentas de laboratório que ajudam a diagnosticar problemas:

• Chrome DevTools (Performance panel): grave uma sessão, interaja com a página e análise os Long Animation Frames (LoAF) para identificar interações lentas
• Web Vitals Extension: extensão do Chrome que mostra INP em tempo real conforme você interage com a página
• CrUX Dashboard: dados de campo reais coletados do Chrome, disponíveis via BigQuery ou PageSpeed Insights
• web-vitals.js: biblioteca JavaScript do Google para medir e reportar INP no seu próprio analytics

Estratégias para otimizar o INP

Na minha operação, estas são as técnicas que mais geram resultado na otimização de INP:

• Quebre Long Tasks: use scheduler.yield() ou setTimeout para dividir tarefas JavaScript longas (acima de 50ms) em chunks menores, permitindo que o navegador processe interações entre elas
• Reduza o peso dos event handlers: mova lógica complexa para Web Workers, debounce interações frequentes e evite manipulações de DOM sincronas em callbacks de clique
• Minimize o JavaScript da main thread: audite dependências, remova scripts não utilizados, implemente code splitting e lazy loading de modulos
• Evite layout thrashing: não leia propriedades de layout (offsetHeight, getBoundingClientRect) e escreva no DOM no mesmo ciclo de execução
• Use content-visibility: auto: permite que o navegador pule a renderização de conteúdo fora da viewport, reduzindo o trabalho de layout em interações

LCP: como otimizar o carregamento

LCP (Largest Contentful Paint) mede o tempo que o maior elemento visível da viewport leva para ser completamente renderizado. Geralmente, o elemento LCP e uma imagem hero, um bloco de texto grande ou um video poster. O limiar e 2.5 segundos: acima disso, o Google considera a experiência degradada.

O LCP permanece como a métrica mais intuitiva das Core Web Vitals, mas também e a que mais sofre com problemas de infraestrutura. Na minha experiência, os problemas de LCP se dividem em quatro categorias:

1. Server Response Time (TTFB)

Se o servidor demora para responder, nenhuma otimização de frontend resolve. O Time to First Byte (TTFB) ideal e abaixo de 800ms. Estratégias:

• Use uma CDN com pontos de presença próximos ao seu público-alvo
• Implemente cache de página no servidor (Redis, Varnish, ou cache na edge com Cloudflare/Vercel)
• Otimize queries de banco de dados. Queries lentas são a causa número 1 de TTFB alto em aplicações dinâmicas
• Considere Static Site Generation (SSG) ou Incremental Static Regeneration (ISR) para páginas que não mudam a cada request

2. Otimização de imagens

Imagens são o elemento LCP mais comum. A otimização correta pode reduzir o LCP em 40-60%:

• Use formatos modernos: WebP ou AVIF com fallback para JPEG
• Implemente responsive images com srcset e sizes para servir o tamanho exato necessário para cada viewport
• Adicione fetchpriority="high" na imagem LCP para que o navegador priorize seu download
• Evite lazy loading na imagem LCP: ela deve carregar imediatamente, não sob demanda
• Use preload no head para imagens LCP que são referenciadas via CSS (backgrounds)

3. Fontes web

Fontes custom podem bloquear a renderização de texto, que frequentemente e o elemento LCP:

• Use font-display: swap para mostrar texto imediatamente com uma fonte fallback
• Faça preload das fontes críticas: <link rel="preload" href="font.woff2" as="font" crossorigin>
• Limite o número de fontes e pesos, cada variação e um arquivo adicional para baixar
• Considere usar fontes de sistema para body text e reservar fontes custom apenas para headings

4. Render-blocking resources

CSS e JavaScript no head podem bloquear a renderização da página inteira:

• Faça inline do CSS crítico (above-the-fold) e carregue o restante de forma assíncrona
• Use defer ou async em scripts que não são necessários para a renderização inicial
• Remova CSS não utilizado, ferramentas como PurgeCSS ajudam a identificar regras orfas

CLS: estabilidade visual

CLS (Cumulative Layout Shift) mede a soma de todos os deslocamentos inesperados de layout que ocorrem durante o ciclo de vida da página. Um layout shift acontece quando um elemento visível muda de posição sem que o usuário tenha interagido com a página. O limiar e 0.1: acima disso, a experiência e considerada instável.

CLS e a métrica que mais irrita usuários sem que eles saibam nomear o problema. Aquele botão que "pula" quando você está prestes a clicar, o conteúdo que desce porque um banner carregou acima, o formulário que se desloca porque uma imagem finalmente renderizou, tudo isso é CLS.

Causas mais comuns de CLS

• Imagens e videos sem dimensões: sem width e height definidos, o navegador não sabe quanto espaço reservar até o asset carregar. Sempre defina dimensões ou use aspect-ratio no CSS
• Anúncios e embeds dinâmicos: ads que carregam tardiamente e "empurram" o conteúdo para baixo. Reserve espaço fixo com min-height para containers de anúncios
• Fontes que causam FOUT/FOIT: quando a fonte custom carrega e substitui a fallback, o texto pode mudar de tamanho. Use font-display: optional ou ajuste size-adjust na @font-face
• Conteúdo injetado dinamicamente: banners de cookies, modais de newsletter e barras de notificação que empurram o conteúdo. Use position: fixed ou sticky em vez de inserir no fluxo do documento
• Componentes client-side rendering: elementos renderizados via JavaScript após o HTML inicial podem causar shifts. Prefira SSR ou reserve espaço com skeletons

Boas práticas para CLS zero

No meu workflow de otimização, sigo estas regras para manter CLS próximo de zero:

• Sempre defina width e height em todas as tags <img> e <video>
• Use aspect-ratio no CSS para containers de mídia: aspect-ratio: 16/9
• Reserve espaço para conteúdo dinâmico com min-height antes que ele carregue
• Posicione banners e notificações com position: fixed ou sticky, nunca no fluxo normal
• Evite inserir elementos acima do conteúdo visível após o carregamento inicial
• Teste com throttling de rede. CLS aparece mais em conexões lentas quando assets demoram para carregar

"CLS e a métrica mais subestimada das Core Web Vitals. Não afeta so ranking, afeta diretamente taxa de conversão. Cada layout shift inesperado e uma oportunidade de clique perdido."

Ferramentas de diagnóstico

Medir Core Web Vitals corretamente exige combinar dados de laboratório (simulados, controlados) com dados de campo (usuários reais). Cada ferramenta tem seu papel:

Google PageSpeed Insights

O ponto de partida para qualquer análise. Combina dados do CrUX (campo) com auditoria Lighthouse (laboratório) em uma única interface. Mostra os valores reais de LCP, INP e CLS dos últimos 28 dias, além de sugestões de otimização priorizadas por impacto. Use para ter uma visão geral e identificar as métricas que precisam de atenção.

Google Lighthouse

Ferramenta de auditoria integrada ao Chrome DevTools. Roda em ambiente controlado (laboratório), o que significa que os valores podem diferir da experiência real dos usuários. Sua força está no diagnóstico detalhado: identifica exatamente quais elementos causam problemas de LCP, quais scripts bloqueiam a main thread e quais elementos geram layout shifts.

Chrome UX Report (CrUX)

O dataset oficial do Google com dados reais de Core Web Vitals coletados de usuários do Chrome que optaram por compartilhar dados de navegação. E o mesmo dataset que o Google usa para ranking. Acessível via BigQuery, API ou pelo CrUX Dashboard no Data Studio. Essencial para entender a experiência real do seu público, segmentada por dispositivo, conexão e localização.

WebPageTest

A ferramenta mais avançada para análise de performance. Permite testar de múltiplas localizações, em diferentes dispositivos e conexões, com filmstrip visual e waterfall detalhado de carregamento. O recurso de comparação A/B e excelente para validar o impacto de otimizações antes de colocar em produção. Use para diagnósticos profundos e para entender a sequência exata de carregamento.

Web Vitals Extension

Extensão leve do Chrome que exibe LCP, INP e CLS em tempo real enquanto você navega. Mostra alertas visuais quando uma métrica ultrapassa o limiar e permite identificar exatamente qual elemento e o LCP ou qual interação causou um INP alto. Ferramenta indispensável para debugging rápido durante o desenvolvimento.

Google Search Console

O relatório de Core Web Vitals no Search Console mostra quais URLs do seu site estão com status "bom", "precisa melhorar" ou "ruim" para cada métrica, agrupadas por padrão de URL. E a visão que o Google tem do seu site. Use para priorizar correções: comece pelas páginas com mais tráfego que estão falhando.

Checklist de otimização

Este e o checklist que uso em todos os projetos de otimização de Core Web Vitals. Siga na ordem, os itens estão priorizados por impacto:

Diagnóstico inicial

1. Rode o PageSpeed Insights nas 10 páginas com mais tráfego e registre LCP, INP e CLS de campo
2. Verifique o relatório de Core Web Vitals no Search Console e identifique grupos de URLs com problemas
3. Faça um teste no WebPageTest com conexão 4G e dispositivo móvel para simular a experiência real do usuário médio
4. Instale a Web Vitals Extension e navegue pelo site interagindo com todos os elementos interativos

Otimização de LCP

1. Identifique o elemento LCP de cada página crítica (Lighthouse mostra isso)
2. Se for imagem: converta para WebP/AVIF, adicione fetchpriority="high", remova lazy loading, implemente srcset
3. Se for texto: faça preload da fonte, use font-display: swap, inline o CSS crítico
4. Otimize o TTFB: ative cache de página, configure CDN, otimize queries do backend
5. Remova ou adie render-blocking resources (CSS e JS não críticos)

Otimização de INP

1. Identifique interações lentas com o Performance panel do DevTools (grave e interaja)
2. Quebre Long Tasks em chunks menores usando yield patterns
3. Audite scripts de terceiros: remova os desnecessários, adie os não críticos
4. Mova lógica pesada para Web Workers
5. Implemente debounce em interações frequentes (scroll, resize, input)

Otimização de CLS

1. Adicione width e height em todas as imagens e videos
2. Reserve espaço para anúncios e embeds com min-height
3. Ajuste fontes com size-adjust ou font-display: optional
4. Mova banners e notificações para position: fixed/sticky
5. Teste com slow 3G para capturar shifts que so aparecem em conexões lentas

Monitoramento contínuo

1. Configure web-vitals.js para enviar dados de campo para seu analytics
2. Crie alertas automáticos quando métricas ultrapassarem os limiares
3. Revise o Search Console semanalmente para detectar regressões
4. Rode auditorias Lighthouse no CI/CD para bloquear deploys que degradem performance

Conclusão

Core Web Vitals em 2026 não são mais uma novidade, são um requisito básico de competitividade. A substituição do FID pelo INP elevou o sarrafo de responsividade, e sites que antes passavam confortavelmente agora precisam de otimizações mais profundas no JavaScript e na arquitetura de interações.

O ponto fundamental e que Core Web Vitals não são apenas sobre ranking: são sobre experiência do usuário, que se traduz em taxa de conversão, engajamento e receita. Na minha experiência, projetos que passam de "precisa melhorar" para "bom" em todas as três métricas veem um aumento médio de 15-25% na taxa de conversão mobile.

Se você está começando, foque nos itens de maior impacto do checklist: otimize imagens para LCP, audite scripts de terceiros para INP e defina dimensões em todas as mídias para CLS. Essas três ações sozinhas resolvem a maioria dos problemas.

Para projetos mais complexos. E-commerces com milhares de páginas, aplicações SPA, sites com muitos scripts de terceiros, uma auditoria técnica aprofundada e o caminho. Se você quer um diagnóstico completo do estado atual das Core Web Vitals do seu site e um plano de ação priorizado, entre em contato.