Core Web Vitals em 2026: como deixar o blog rápido no LCP, INP e CLS pra ganhar leitor e busca

Resposta curta: Core Web Vitals são as três métricas do Google que medem a experiência real de quem abre o seu blog: LCP (carregamento), INP (resposta ao toque ou clique) e CLS (estabilidade visual). A meta é LCP de até 2,5 segundos, INP de até 200 milissegundos e CLS de até 0,1, medidos no percentil 75 das visitas.

Um post bom que demora pra aparecer, trava quando a pessoa toca no menu ou pula o texto quando a imagem termina de carregar perde leitor antes do primeiro parágrafo. E o leitor que vem do X, do LinkedIn ou do Threads costuma chegar pelo celular, muitas vezes com conexão pior do que a sua.

Este guia junta o que a documentação do Google Search Central e os guias do web.dev (mantidos pelo time do Chrome) dizem sobre Core Web Vitals, conferidos em 27 de outubro de 2026. Ele explica o que cada métrica mede, onde ver os números do seu blog e quais correções dão mais resultado num blog de conteúdo.

O que são Core Web Vitals e por que importam pro blog

O Google define Core Web Vitals como um conjunto de métricas que medem a experiência real do usuário em três frentes: desempenho de carregamento, interatividade e estabilidade visual da página. A recomendação oficial é que donos de site atinjam bons valores "para ter sucesso na Busca" e pra garantir uma boa experiência em geral.

Vale entender o peso certo disso. Na página sobre experiência de página, o Google diz três coisas que ajudam a calibrar o esforço:

• Os Core Web Vitals são usados pelos sistemas de ranqueamento.
• Ter bons resultados no relatório do Search Console ou em ferramentas de terceiros não garante que a página vai ficar no topo, e buscar a nota perfeita só por SEO "pode não ser o melhor uso do seu tempo".
• O Google sempre tenta mostrar o conteúdo mais relevante, mesmo com experiência de página ruim. Mas quando existem muitas páginas úteis sobre o mesmo assunto, uma boa experiência pode ajudar.

Na prática: velocidade não salva um post fraco, mas pode desempatar contra concorrentes parecidos. E o efeito no leitor é imediato, porque ninguém espera uma página lenta só porque o link apareceu no feed.

As três métricas e os limites de cada uma

Os três limites abaixo valem pra todas as páginas e são medidos no percentil 75 das visitas, separando celular e computador. Ou seja, pelo menos 75% das visitas precisam ficar dentro da meta. Segundo o web.dev, uma página passa na avaliação quando atinge as três metas ao mesmo tempo.

Pra INP, o web.dev considera ruim acima de 500 milissegundos. Pra CLS, ruim é acima de 0,25. Entre a meta e o ruim, a métrica fica como "precisa melhorar".

O INP substituiu o FID (First Input Delay) como métrica de interatividade, e as três métricas estão hoje no estágio "estável" do ciclo de vida descrito pelo web.dev. O próprio guia avisa que as métricas mudam no máximo uma vez por ano, com aviso prévio no changelog oficial.

Onde ver os números do seu blog

Existem dois tipos de dado, e confundir os dois é o erro mais comum.

Dados de campo vêm de visitas reais. O Chrome User Experience Report (CrUX) coleta essas medições de forma anônima e alimenta o PageSpeed Insights e o relatório de Core Web Vitals do Search Console. É esse dado que reflete o que o leitor sente.

Dados de laboratório vêm de um teste simulado, como o Lighthouse ou o painel Performance do Chrome DevTools. Servem pra achar a causa e testar uma correção antes de publicar, mas o web.dev deixa claro que não substituem o dado de campo. O Lighthouse nem mede INP: no lugar dele usa o TBT (Total Blocking Time) como aproximação.

Um caminho simples pra começar:

1. Abra o relatório de Core Web Vitals no Search Console. Ele agrupa URLs parecidas e mostra o status como Ruim, Precisa melhorar ou Bom, separado por celular e computador. O status de um grupo é o da pior métrica dele.
2. Se o relatório disser "Nenhum dado disponível", a propriedade é nova ou o blog ainda não tem visitas suficientes no CrUX. Nesse caso, teste URLs individuais no PageSpeed Insights.
3. No PageSpeed Insights, compare a parte de usuários reais com a parte de diagnóstico. Se o CLS real for bem maior que o do teste, o problema provavelmente acontece depois do carregamento, por exemplo quando a pessoa rola a página.
4. Use o Lighthouse ou o DevTools pra descobrir qual elemento é o LCP e o que se moveu na tela.

Se você ainda não configurou o Search Console, o guia Google Search Console em 2026 mostra o passo a passo. Lembre que só URLs indexadas aparecem no relatório.

Como melhorar cada métrica num blog de conteúdo

A ordem que costuma render mais num blog é começar pela capa (LCP), depois pelo que pula na tela (CLS) e por fim pelos scripts (INP).

LCP: a capa é quase sempre a culpada

Num blog, o maior elemento visível costuma ser a imagem de capa. O web.dev cita o Web Almanac 2024 do HTTP Archive: 73% das páginas no celular têm uma imagem como elemento de LCP. O mesmo guia diz que 40% dos sites no Chrome UX Report não atingem o limite recomendado de LCP, o que faz dela a métrica em que os desenvolvedores mais travam.

As correções que o time do Chrome aponta como mais eficazes:

• Deixe a capa visível no HTML. Use uma tag <img> com src ou srcset. Evite atributos como data-src, que dependem de JavaScript pra mostrar a imagem.
• Prefira renderização no servidor. Quando a página é montada no navegador, o JavaScript precisa rodar antes de a imagem ser descoberta.
• Dê prioridade à capa. Adicione fetchpriority="high" na imagem de capa.
• Tire o loading="lazy" da capa. Carregamento preguiçoso é ótimo pras imagens do meio do texto, mas atrasa a primeira imagem da tela.
• Use uma CDN. Servir o HTML e as imagens de um servidor perto do leitor reduz o tempo até o primeiro byte (TTFB), que vem antes de tudo.

Arquivo leve também ajuda. O guia SEO de imagens em 2026 cobre formato, tamanho e texto alternativo das imagens do blog.

CLS: reserve espaço antes de carregar

CLS é a métrica em que a maioria dos sites vai bem, mas o web.dev diz que cerca de um quarto ainda não atinge a meta. As causas mais comuns, segundo o guia de otimização de CLS, são imagens sem dimensões, anúncios e embeds sem tamanho, conteúdo injetado depois do carregamento e fontes web.

O que fazer num blog:

• Coloque width e height em toda imagem e vídeo. O navegador usa esses valores pra calcular a proporção e reservar o espaço antes do arquivo chegar. O web.dev diz que 66% das páginas têm pelo menos uma imagem sem tamanho definido.
• Reserve espaço pra embeds. Post do X, vídeo do YouTube e mapa costumam não saber o próprio tamanho antes de carregar. Use min-height ou aspect-ratio no contêiner.
• Não empurre o texto com banners. Banner de cookies ou de newsletter que entra pelo topo e empurra o conteúdo gera deslocamento. Prefira sobrepor o conteúdo ou reservar o espaço.
• Anime com transform. Animar top, left, margin ou border provoca recálculo de layout. transform não.
• Cuide das fontes. Use uma fonte de reserva parecida, font-display: optional quando fizer sentido e <link rel="preload"> nas fontes críticas.
• Deixe a página elegível pro bfcache. O cache de voltar e avançar do navegador restaura a página exatamente como estava, sem deslocamentos.

INP: menos JavaScript, menos espera

INP mede o tempo entre a ação do leitor (tocar no menu, abrir um FAQ, clicar em "copiar link") e a próxima atualização da tela. O web.dev chama de tarefa longa qualquer trabalho do navegador que passa de 50 milissegundos, porque ela bloqueia a resposta à interação.

Num blog de conteúdo, o vilão costuma ser o que foi sendo instalado com o tempo: scripts de análise, chat, pop-ups, widgets de compartilhamento e tags antigas. O guia de prioridades do Chrome recomenda:

• Cortar JavaScript que não precisa estar ali. A ferramenta Coverage do DevTools mostra código carregado e não usado.
• Revisar o gerenciador de tags periodicamente, removendo tags antigas.
• Quebrar tarefas longas em partes menores, cedendo a vez pro navegador responder.
• Manter o DOM pequeno. Páginas com estrutura muito grande deixam cada atualização de layout mais cara.

Checklist rápido antes de publicar um post

Use esta lista em cada post novo. Ela leva poucos minutos e evita a maior parte dos problemas:

• A capa está no HTML, sem loading="lazy" e com fetchpriority="high".
• Toda imagem tem width, height e texto alternativo.
• Embeds de redes sociais ou vídeo têm espaço reservado.
• Nenhum banner novo empurra o texto.
• Nenhum script novo de terceiro foi adicionado sem necessidade.
• O post foi testado no PageSpeed Insights no modo celular.
• A prévia de link funciona, com og:image apontando pra capa. Veja o guia de prévia de link com Open Graph.

Velocidade é uma parte do trabalho técnico. As outras são sitemap, dados estruturados e o que ajuda a IA a citar seu conteúdo, que está no checklist de AEO e GEO.

Onde o Otto entra

O Otto não mexe no código do seu blog, e o trabalho deste guia continua sendo seu ou do seu desenvolvedor. O que o Otto resolve é a outra metade: levar leitor pro post. Ele escreve e agenda os posts do X, do LinkedIn e do Threads que divulgam cada artigo, no seu tom de voz, pra você gastar o tempo que sobra deixando a página rápida pra quem chega.

Quer automatizar a divulgação dos seus posts? Conheça o Otto em otto.doti.gg.

Perguntas frequentes

Core Web Vitals é fator de ranqueamento? Sim. O Google diz que os Core Web Vitals são usados pelos sistemas de ranqueamento, mas que não existe um único "sinal de experiência de página" e que nota boa não garante o topo. Relevância continua vindo primeiro.

Preciso tirar 100 no PageSpeed Insights? Não. A nota do teste de laboratório ajuda a diagnosticar, mas o que conta é o dado de campo. O Google avisa que perseguir a nota perfeita só por SEO pode não valer o tempo.

O Google avalia o site inteiro ou cada página? Os sistemas do Google avaliam em geral página por página, inclusive a experiência de página, mas o Google diz que também faz algumas avaliações no nível do site.

Por que o Search Console mostra "Nenhum dado disponível"? Porque a propriedade é nova ou porque o blog ainda não tem visitas reais suficientes no CrUX. Enquanto isso, teste as URLs no PageSpeed Insights ou no Lighthouse.

O que aconteceu com o FID? O INP substituiu o FID como métrica de interatividade dos Core Web Vitals. Ferramentas e guias atuais já usam INP.

Fontes

• Understanding Core Web Vitals and Google search results, Google Search Central: definição das três métricas e metas de LCP, INP e CLS. Conferida em 27/10/2026.
• Understanding page experience in Google Search results, Google Search Central: uso dos Core Web Vitals no ranqueamento, avaliação por página e limites do que a nota garante. Conferida em 27/10/2026.
• Web Vitals, web.dev: metas, percentil 75, ciclo de vida das métricas e ferramentas de campo e laboratório. Conferida em 27/10/2026.
• The most effective ways to improve Core Web Vitals, web.dev: prioridades do time do Chrome e dados do Web Almanac e do CrUX citados no texto. Conferida em 27/10/2026.
• Optimize Cumulative Layout Shift, web.dev: limites de CLS e causas comuns, como imagens sem dimensões, embeds e fontes. Conferida em 27/10/2026.
• Interaction to Next Paint (INP), web.dev: limites de INP bom, a melhorar e ruim. Conferida em 27/10/2026.
• Largest Contentful Paint (LCP), web.dev: meta de LCP e percentil de medição. Conferida em 27/10/2026.
• Core Web Vitals report, Ajuda do Search Console: como o relatório agrupa URLs e o que significa "Nenhum dado disponível". Conferida em 27/10/2026.
• PageSpeed Insights: teste de URLs individuais com dado de campo e de laboratório. Conferida em 27/10/2026.