# Core Web Vitals em 2026: como deixar o blog rápido no LCP, INP e CLS pra ganhar leitor e busca
O que o Google e o web.dev dizem sobre LCP, INP e CLS: as metas de cada métrica, onde medir no Search Console e no PageSpeed Insights e as correções que mais aceleram um blog.
Fonte: https://otto.doti.gg/blog/core-web-vitals-em-2026-como-deixar-o-blog-rapido-no-lcp-inp-e-cls-pra-ganhar-leitor-e-busca
Autor: Isaque Coelho
Publicado: 2026-10-27T20:02:05.891Z
Atualizado: 2026-10-27T20:02:05.891Z
Categoria: Alcance e viralização
**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.
| Métrica | O que mede | Meta (bom) | O que costuma estragar num blog |
| --- | --- | --- | --- |
| LCP (Largest Contentful Paint) | Quanto tempo o maior elemento visível, como a capa ou o título, leva pra aparecer | Até 2,5 s | Capa pesada, capa com carregamento preguiçoso, servidor lento |
| INP (Interaction to Next Paint) | Quanto tempo a página leva pra responder a um clique, toque ou tecla | Até 200 ms | JavaScript demais, scripts de terceiros, widgets |
| CLS (Cumulative Layout Shift) | Quanto o conteúdo pula de lugar enquanto a pessoa lê | Até 0,1 | Imagem sem tamanho, anúncio, banner de cookies, fonte web |
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](https://otto.doti.gg/blog/google-search-console-em-2026-como-saber-se-os-posts-do-blog-aparecem-no-google-e-ganham-clique) 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 `` 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](https://otto.doti.gg/blog/seo-de-imagens-em-2026-como-fazer-as-imagens-do-blog-aparecerem-no-google-imagens-no-discover-e-na-i) 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 `` 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](https://otto.doti.gg/blog/previa-de-link-em-2026-como-configurar-open-graph-pro-seu-link-aparecer-com-imagem-no-x-no-linkedin).
Velocidade é uma parte do trabalho técnico. As outras são [sitemap](https://otto.doti.gg/blog/sitemap-xml-em-2026-como-criar-e-enviar-o-sitemap-do-blog-pro-google-achar-cada-post-novo), [dados estruturados](https://otto.doti.gg/blog/dados-estruturados-em-2026-como-usar-schema-no-blog-pro-google-e-a-ia-entenderem-cada-post) e o que ajuda a IA a citar seu conteúdo, que está no [checklist de AEO e GEO](https://otto.doti.gg/blog/aeo-e-geo-em-2026-como-ser-citado-por-ia-e-pelo-google-com-um-checklist-tecnico-e-de-escrita).
## 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](https://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](https://developers.google.com/search/docs/appearance/core-web-vitals): 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](https://developers.google.com/search/docs/appearance/page-experience): 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](https://web.dev/articles/vitals): 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](https://web.dev/articles/top-cwv): 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](https://web.dev/articles/optimize-cls): 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](https://web.dev/articles/inp): limites de INP bom, a melhorar e ruim. Conferida em 27/10/2026.
- [Largest Contentful Paint (LCP), web.dev](https://web.dev/articles/lcp): meta de LCP e percentil de medição. Conferida em 27/10/2026.
- [Core Web Vitals report, Ajuda do Search Console](https://support.google.com/webmasters/answer/9205520): como o relatório agrupa URLs e o que significa "Nenhum dado disponível". Conferida em 27/10/2026.
- [PageSpeed Insights](https://pagespeed.web.dev/): teste de URLs individuais com dado de campo e de laboratório. Conferida em 27/10/2026.