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

O que sao Core Web Vitals em 2026

Core Web Vitals sao um conjunto de metricas definidas pelo Google para avaliar a experiencia real do usuario em uma pagina web. Desde marco de 2024, o conjunto oficial passou a ser composto por tres metricas: LCP (Largest Contentful Paint), INP (Interaction to Next Paint) e CLS (Cumulative Layout Shift). Cada uma mede uma dimensao diferente da experiencia: velocidade de carregamento, responsividade a interacoes e estabilidade visual.

A mudanca mais relevante dos ultimos anos foi a substituicao do FID (First Input Delay) pelo INP (Interaction to Next Paint) em marco de 2024. O FID media apenas a primeira interacao do usuario e ignorava tudo o que acontecia depois. O INP corrigiu essa limitacao ao medir todas as interacoes durante o ciclo de vida da pagina, oferecendo uma visao muito mais realista da responsividade.

Na pratica, sites que passavam facilmente no FID comecaram a falhar no INP. Na minha experiencia com mais de 500 projetos, estimo que 35% dos sites que tinham FID "bom" passaram a ter INP "precisa melhorar" ou "ruim" apos a transicao. Isso acontece porque o FID era uma metrica generosa demais — media apenas o delay da primeira interacao, sem considerar o tempo de processamento nem o tempo ate a proxima renderizacao.

Os limiares atuais para cada metrica sao:

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

Essas metricas nao sao apenas tecnicalidades — elas impactam diretamente o ranking no Google. O Page Experience Update integrou Core Web Vitals como sinal de classificacao, e em 2026 esse peso so aumentou, especialmente em mercados competitivos onde dezenas de paginas concorrem pela mesma keyword com conteudo de qualidade similar.

INP: a nova metrica que substituiu o FID

INP (Interaction to Next Paint) mede o tempo entre uma interacao do usuario (clique, toque ou pressionamento de tecla) e o momento em que o navegador consegue renderizar a proxima frame visual como resultado dessa interacao. Diferente do FID, que media apenas o input delay da primeira interacao, o INP captura tres componentes de cada interacao:

1. Input Delay — o tempo entre a interacao do usuario e o inicio do processamento do event handler. Acontece quando a main thread esta ocupada com outras tarefas.
2. Processing Time — o tempo que os event handlers JavaScript levam para executar. Callbacks pesados, manipulacoes de DOM complexas e calculos intensivos inflam esse valor.
3. Presentation Delay — o tempo entre o final do processamento e a proxima frame renderizada pelo navegador. Layout recalculations, paint e compositing acontecem aqui.

O INP reporta o pior valor observado durante toda a sessao do usuario (com uma tolerancia estatistica para outliers em sessoes com muitas interacoes). Isso significa que uma unica interacao lenta — como um clique em um botao de filtro que trava por 800ms — pode comprometer o INP inteiro da pagina.

Como medir o INP

O INP e uma metrica de campo, ou seja, e medida com dados reais de usuarios (RUM — Real User Monitoring). No entanto, existem ferramentas de laboratorio que ajudam a diagnosticar problemas:

• Chrome DevTools (Performance panel) — grave uma sessao, interaja com a pagina e analise os Long Animation Frames (LoAF) para identificar interacoes lentas
• Web Vitals Extension — extensao do Chrome que mostra INP em tempo real conforme voce interage com a pagina
• CrUX Dashboard — dados de campo reais coletados do Chrome, disponiveis via BigQuery ou PageSpeed Insights
• web-vitals.js — biblioteca JavaScript do Google para medir e reportar INP no seu proprio analytics

Estrategias para otimizar o INP

Na minha operacao, estas sao as tecnicas que mais geram resultado na otimizacao 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 interacoes entre elas
• Reduza o peso dos event handlers — mova logica complexa para Web Workers, debounce interacoes frequentes e evite manipulacoes de DOM sincronas em callbacks de clique
• Minimize o JavaScript da main thread — audite dependencias, remova scripts nao utilizados, implemente code splitting e lazy loading de modulos
• Evite layout thrashing — nao leia propriedades de layout (offsetHeight, getBoundingClientRect) e escreva no DOM no mesmo ciclo de execucao
• Use content-visibility: auto — permite que o navegador pule a renderizacao de conteudo fora da viewport, reduzindo o trabalho de layout em interacoes

LCP: como otimizar o carregamento

LCP (Largest Contentful Paint) mede o tempo que o maior elemento visivel 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 experiencia degradada.

O LCP permanece como a metrica mais intuitiva das Core Web Vitals, mas tambem e a que mais sofre com problemas de infraestrutura. Na minha experiencia, os problemas de LCP se dividem em quatro categorias:

1. Server Response Time (TTFB)

Se o servidor demora para responder, nenhuma otimizacao de frontend resolve. O Time to First Byte (TTFB) ideal e abaixo de 800ms. Estrategias:

• Use uma CDN com pontos de presenca proximos ao seu publico-alvo
• Implemente cache de pagina no servidor (Redis, Varnish, ou cache na edge com Cloudflare/Vercel)
• Otimize queries de banco de dados — queries lentas sao a causa numero 1 de TTFB alto em aplicacoes dinamicas
• Considere Static Site Generation (SSG) ou Incremental Static Regeneration (ISR) para paginas que nao mudam a cada request

2. Otimizacao de imagens

Imagens sao o elemento LCP mais comum. A otimizacao 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 necessario 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, nao sob demanda
• Use preload no head para imagens LCP que sao referenciadas via CSS (backgrounds)

3. Fontes web

Fontes custom podem bloquear a renderizacao de texto, que frequentemente e o elemento LCP:

• Use font-display: swap para mostrar texto imediatamente com uma fonte fallback
• Faca preload das fontes criticas: <link rel="preload" href="font.woff2" as="font" crossorigin>
• Limite o numero de fontes e pesos — cada variacao 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 renderizacao da pagina inteira:

• Faça inline do CSS critico (above-the-fold) e carregue o restante de forma assincrona
• Use defer ou async em scripts que nao sao necessarios para a renderizacao inicial
• Remova CSS nao 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 pagina. Um layout shift acontece quando um elemento visivel muda de posicao sem que o usuario tenha interagido com a pagina. O limiar e 0.1 — acima disso, a experiencia e considerada instavel.

CLS e a metrica que mais irrita usuarios sem que eles saibam nomear o problema. Aquele botao que "pula" quando voce esta prestes a clicar, o conteudo que desce porque um banner carregou acima, o formulario que se desloca porque uma imagem finalmente renderizou — tudo isso e CLS.

Causas mais comuns de CLS

• Imagens e videos sem dimensoes — sem width e height definidos, o navegador nao sabe quanto espaco reservar ate o asset carregar. Sempre defina dimensoes ou use aspect-ratio no CSS
• Anuncios e embeds dinamicos — ads que carregam tardiamente e "empurram" o conteudo para baixo. Reserve espaco fixo com min-height para containers de anuncios
• 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
• Conteudo injetado dinamicamente — banners de cookies, modais de newsletter e barras de notificacao que empurram o conteudo. Use position: fixed ou sticky em vez de inserir no fluxo do documento
• Componentes client-side rendering — elementos renderizados via JavaScript apos o HTML inicial podem causar shifts. Prefira SSR ou reserve espaco com skeletons

Boas praticas para CLS zero

No meu workflow de otimizacao, sigo estas regras para manter CLS proximo de zero:

• Sempre defina width e height em todas as tags <img> e <video>
• Use aspect-ratio no CSS para containers de midia: aspect-ratio: 16/9
• Reserve espaco para conteudo dinamico com min-height antes que ele carregue
• Posicione banners e notificacoes com position: fixed ou sticky, nunca no fluxo normal
• Evite inserir elementos acima do conteudo visivel apos o carregamento inicial
• Teste com throttling de rede — CLS aparece mais em conexoes lentas quando assets demoram para carregar

"CLS e a metrica mais subestimada das Core Web Vitals. Nao afeta so ranking — afeta diretamente taxa de conversao. Cada layout shift inesperado e uma oportunidade de clique perdido."

Ferramentas de diagnostico

Medir Core Web Vitals corretamente exige combinar dados de laboratorio (simulados, controlados) com dados de campo (usuarios reais). Cada ferramenta tem seu papel:

Google PageSpeed Insights

O ponto de partida para qualquer analise. Combina dados do CrUX (campo) com auditoria Lighthouse (laboratorio) em uma unica interface. Mostra os valores reais de LCP, INP e CLS dos ultimos 28 dias, alem de sugestoes de otimizacao priorizadas por impacto. Use para ter uma visao geral e identificar as metricas que precisam de atencao.

Google Lighthouse

Ferramenta de auditoria integrada ao Chrome DevTools. Roda em ambiente controlado (laboratorio), o que significa que os valores podem diferir da experiencia real dos usuarios. Sua forca esta no diagnostico 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 usuarios do Chrome que optaram por compartilhar dados de navegacao. E o mesmo dataset que o Google usa para ranking. Acessivel via BigQuery, API ou pelo CrUX Dashboard no Data Studio. Essencial para entender a experiencia real do seu publico, segmentada por dispositivo, conexao e localizacao.

WebPageTest

A ferramenta mais avancada para analise de performance. Permite testar de multiplas localizacoes, em diferentes dispositivos e conexoes, com filmstrip visual e waterfall detalhado de carregamento. O recurso de comparacao A/B e excelente para validar o impacto de otimizacoes antes de colocar em producao. Use para diagnosticos profundos e para entender a sequencia exata de carregamento.

Web Vitals Extension

Extensao leve do Chrome que exibe LCP, INP e CLS em tempo real enquanto voce navega. Mostra alertas visuais quando uma metrica ultrapassa o limiar e permite identificar exatamente qual elemento e o LCP ou qual interacao causou um INP alto. Ferramenta indispensavel para debugging rapido durante o desenvolvimento.

Google Search Console

O relatorio de Core Web Vitals no Search Console mostra quais URLs do seu site estao com status "bom", "precisa melhorar" ou "ruim" para cada metrica, agrupadas por padrao de URL. E a visao que o Google tem do seu site. Use para priorizar correcoes: comece pelas paginas com mais trafego que estao falhando.

Checklist de otimizacao

Este e o checklist que uso em todos os projetos de otimizacao de Core Web Vitals. Siga na ordem — os itens estao priorizados por impacto:

Diagnostico inicial

1. Rode o PageSpeed Insights nas 10 paginas com mais trafego e registre LCP, INP e CLS de campo
2. Verifique o relatorio de Core Web Vitals no Search Console e identifique grupos de URLs com problemas
3. Faca um teste no WebPageTest com conexao 4G e dispositivo movel para simular a experiencia real do usuario medio
4. Instale a Web Vitals Extension e navegue pelo site interagindo com todos os elementos interativos

Otimizacao de LCP

1. Identifique o elemento LCP de cada pagina critica (Lighthouse mostra isso)
2. Se for imagem: converta para WebP/AVIF, adicione fetchpriority="high", remova lazy loading, implemente srcset
3. Se for texto: faca preload da fonte, use font-display: swap, inline o CSS critico
4. Otimize o TTFB: ative cache de pagina, configure CDN, otimize queries do backend
5. Remova ou adie render-blocking resources (CSS e JS nao criticos)

Otimizacao de INP

1. Identifique interacoes 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 desnecessarios, adie os nao criticos
4. Mova logica pesada para Web Workers
5. Implemente debounce em interacoes frequentes (scroll, resize, input)

Otimizacao de CLS

1. Adicione width e height em todas as imagens e videos
2. Reserve espaco para anuncios e embeds com min-height
3. Ajuste fontes com size-adjust ou font-display: optional
4. Mova banners e notificacoes para position: fixed/sticky
5. Teste com slow 3G para capturar shifts que so aparecem em conexoes lentas

Monitoramento continuo

1. Configure web-vitals.js para enviar dados de campo para seu analytics
2. Crie alertas automaticos quando metricas ultrapassarem os limiares
3. Revise o Search Console semanalmente para detectar regressoes
4. Rode auditorias Lighthouse no CI/CD para bloquear deploys que degradem performance

Conclusao

Core Web Vitals em 2026 nao sao mais uma novidade — sao um requisito basico de competitividade. A substituicao do FID pelo INP elevou o sarrafo de responsividade, e sites que antes passavam confortavelmente agora precisam de otimizacoes mais profundas no JavaScript e na arquitetura de interacoes.

O ponto fundamental e que Core Web Vitals nao sao apenas sobre ranking — sao sobre experiencia do usuario, que se traduz em taxa de conversao, engajamento e receita. Na minha experiencia, projetos que passam de "precisa melhorar" para "bom" em todas as tres metricas veem um aumento medio de 15-25% na taxa de conversao mobile.

Se voce esta comecando, foque nos itens de maior impacto do checklist: otimize imagens para LCP, audite scripts de terceiros para INP e defina dimensoes em todas as midias para CLS. Essas tres acoes sozinhas resolvem a maioria dos problemas.

Para projetos mais complexos — e-commerces com milhares de paginas, aplicacoes SPA, sites com muitos scripts de terceiros — uma auditoria tecnica aprofundada e o caminho. Se voce quer um diagnostico completo do estado atual das Core Web Vitals do seu site e um plano de acao priorizado, entre em contato.