Core Web Vitals para Blogs: Como LCP, INP e CLS Decidem se o Leitor Fica

Um blog pode ter o melhor texto do nicho e ainda assim perder o leitor nos primeiros dois segundos — não pelo conteúdo, mas pela experiência de carregamento. A pessoa toca no link, a tela fica branca, um bloco de anúncio aparece e empurra o parágrafo que ela ia ler, ela toca num botão que não responde, e volta para a busca. Nada disso tem a ver com a qualidade da escrita. Tem a ver com o que o Google chama de Core Web Vitals: um conjunto de três métricas que tentam capturar, em números, como é a sensação de usar uma página.

Essas métricas importam por dois motivos que se reforçam. Elas são sinal de ranking, usadas pelo buscador para desempatar páginas de qualidade parecida. E, mais importante, elas medem algo que existe independentemente do Google: a paciência do seu leitor. Um blog rápido retém mais, converte mais newsletter, exibe mais anúncios de fato vistos. Este artigo explica cada uma das três, o que as degrada num blog típico e o que fazer a respeito sem precisar virar engenheiro de front-end.

As três métricas e o que cada uma sente#

Os Core Web Vitals medem três dimensões distintas da experiência, e é importante não confundi-las porque as causas e as correções são diferentes.

O LCP (Largest Contentful Paint) mede o carregamento percebido: quanto tempo até o maior elemento visível — normalmente a imagem de destaque ou o bloco de título — aparecer na tela. É a resposta à pergunta "quando é que parece que a página carregou?". O alvo é 2,5 segundos ou menos no percentil 75 dos acessos reais. Acima de 4 segundos é considerado ruim.

O INP (Interaction to Next Paint) mede a responsividade: quando o usuário toca ou clica, quanto tempo até a tela reagir visualmente. Ele substituiu o antigo FID em março de 2024 e é mais rigoroso, porque observa todas as interações da visita, não apenas a primeira. O alvo é 200 milissegundos ou menos; acima de 500 ms é ruim. Num blog, o INP costuma ser degradado por scripts de terceiros — widgets de comentário, tags de anúncio, rastreadores — que ocupam a thread principal justo quando o leitor quer interagir.

O CLS (Cumulative Layout Shift) mede a estabilidade visual: o quanto o conteúdo pula de lugar enquanto carrega. É a métrica mais irritante do ponto de vista humano — é o anúncio que aparece e desloca o texto, fazendo você tocar no lugar errado. O alvo é 0,1 ou menos. CLS não é sobre velocidade; é sobre previsibilidade.

Um detalhe que muda tudo: essas métricas são avaliadas com dados de campo, coletados de visitantes reais, e não com o teste sintético que você roda no seu computador rápido com internet de fibra. Uma página que voa na sua máquina pode falhar no percentil 75 porque metade do seu público está num celular intermediário numa rede móvel instável. Otimizar para o laboratório e ignorar o campo é otimizar para a pessoa errada.

Por que o LCP de um blog costuma estourar#

Num blog, o elemento LCP é quase sempre a imagem de destaque no topo do artigo ou o bloco de texto do título. Os culpados por um LCP lento são previsíveis. O primeiro é a imagem pesada: uma foto de 2 MB servida em tamanho original para uma coluna de 700 pixels desperdiça banda e tempo. Servir imagens em formatos modernos como WebP ou AVIF, redimensionadas para o tamanho de exibição, costuma cortar o LCP pela metade.

O segundo culpado é o carregamento tardio aplicado onde não devia. Lazy loading é excelente para imagens abaixo da dobra, mas aplicá-lo à imagem de destaque — justamente o elemento LCP — atrasa o que deveria ser priorizado. A imagem do herói nunca deve ser lazy; ela deve, ao contrário, receber prioridade alta de carregamento para o navegador buscá-la antes de tudo.

O terceiro é o bloqueio por recursos. Fontes web que travam o texto até baixarem, CSS que impede a renderização, JavaScript síncrono no cabeçalho — tudo isso atrasa o momento em que o conteúdo aparece. Fontes devem usar exibição com fallback imediato, e o JavaScript não essencial deve carregar sem bloquear a renderização. A regra mental é simples: nada que não seja o próprio conteúdo principal deve ter permissão para atrasar o conteúdo principal.

INP: o custo escondido dos scripts de terceiros#

O INP é onde os blogs mais sofrem sem perceber, porque o vilão raramente é o código do próprio blog — é o que se pendura nele. Cada tag de anúncio, cada pixel de rastreamento, cada widget de rede social e cada plugin de comentário executa JavaScript na mesma thread principal que precisa responder ao toque do usuário. Quando essa thread está ocupada processando um leilão de anúncio, o toque do leitor entra numa fila e a tela demora a reagir.

A correção começa por uma auditoria honesta de terceiros. Todo script de terceiro é uma dívida de performance que você assumiu em troca de algum benefício; a pergunta é se o benefício ainda paga a dívida. Aquele widget de rede social que ninguém clica, o rastreador redundante, o plugin abandonado — cada um que sai devolve responsividade. Os que ficam devem ser carregados de forma assíncrona e, quando possível, adiados até depois da interação inicial ou movidos para fora da thread principal.

O segundo movimento é reduzir o trabalho do próprio JavaScript. Num blog, a maior parte da página é conteúdo estático que não precisa de JavaScript nenhum para existir. Quanto mais a página for HTML servido pronto e menos ela depender de scripts para montar o conteúdo, melhor o INP. Frameworks que enviam a página renderizada do servidor e hidratam só o necessário na folha vencem, nesse quesito, arquiteturas que montam tudo no navegador.

CLS: reservar espaço é quase toda a solução#

O CLS tem a correção mais direta das três, o que o torna o mais imperdoável quando falha. Layout shift acontece porque um elemento aparece depois do restante e empurra o que já estava na tela. A solução é reservar o espaço antes.

Toda imagem e todo vídeo embutido devem declarar largura e altura, para que o navegador reserve o retângulo certo antes mesmo do arquivo chegar. Isso sozinho elimina a maior fonte de CLS em blogs. Anúncios são a segunda fonte: um slot de anúncio deve ter dimensões reservadas, um contêiner de tamanho fixo onde o anúncio cai sem deslocar nada. Um anúncio que aparece do nada num espaço não reservado é a receita clássica do leitor que toca no link errado e vai embora frustrado.

Fontes também contribuem. Quando uma fonte web substitui a fonte de fallback e as duas têm métricas diferentes, o texto re-flui e desloca o que está abaixo. Ajustar o fallback para casar com as métricas da fonte final, ou aceitar a fonte do sistema, elimina esse salto. O princípio geral do CLS é um só: o navegador não deveria ter surpresas sobre onde as coisas vão ficar.

Imagens: a maior alavanca de performance de um blog#

Se há um único ponto onde a maioria dos blogs mais ganha com menos esforço, é o tratamento de imagens. Blogs são visuais por natureza — a foto de destaque, as ilustrações no meio do texto, as capturas de tela — e imagens mal tratadas são, de longe, a fonte mais comum de páginas lentas. A boa notícia é que a correção é quase mecânica e rende desproporcionalmente.

O primeiro erro é o tamanho de arquivo. Uma foto exportada direto da câmera ou de um banco de imagens vem com resolução e peso pensados para impressão, não para tela. Servir uma imagem de vários megabytes onde bastariam algumas centenas de kilobytes desperdiça a banda do leitor e atrasa o LCP. Comprimir as imagens e servi-las em formatos modernos como WebP ou AVIF, que entregam a mesma qualidade visual com uma fração do peso, é o ganho mais barato disponível.

O segundo é servir a imagem no tamanho errado de dimensão. Uma foto de 4000 pixels de largura numa coluna de texto de 700 pixels obriga o navegador a baixar quatro vezes mais dados do que usaria, e ainda gasta processamento redimensionando. Servir cada imagem próxima do tamanho em que ela realmente aparece — e oferecer variantes para telas de tamanhos diferentes — corta desperdício sem que o leitor perceba qualquer perda.

O terceiro é a ausência de estratégia de carregamento. A imagem de destaque, que costuma ser o elemento LCP, deve carregar com prioridade alta e nunca ser adiada. As imagens abaixo da dobra, ao contrário, devem usar carregamento tardio para não competir com o conteúdo inicial. Essa distinção — priorizar o que está à vista, adiar o que não está — organiza o carregamento na ordem que o leitor de fato precisa. Tratadas essas três frentes, um blog tipicamente ganha mais em Core Web Vitals do que ganharia com qualquer outra otimização isolada.

Medir onde o leitor está, não onde você está#

O erro estratégico mais comum com Core Web Vitals é medir no lugar errado. O teste que você roda no navegador do desktop, com cache quente e rede boa, mede a experiência que quase ninguém do seu público tem. Os números que importam para o ranking e para a retenção vêm do campo — dos celulares reais dos seus leitores reais, agregados no percentil 75. O Google disponibiliza esses dados de campo, e é a eles que você deve olhar; o teste sintético serve para diagnosticar causas, não para declarar vitória.

Há um momento em que os Core Web Vitals deixam de ser um problema de ajuste e viram um problema de fundação: quando a plataforma em que o blog roda é lenta por arquitetura, carregada de scripts que você não controla, e nenhum ajuste de imagem resolve. Nesse ponto a decisão certa pode ser trocar a base, e vale entender o que está em jogo antes de migrar de plataforma de blog sem quebrar o que já funciona. Performance, no fim, é tanto uma questão de disciplina no dia a dia quanto de escolher uma fundação que não trabalhe contra você.

O resultado que os números representam#

É fácil tratar Core Web Vitals como uma nota escolar a ser satisfeita, mais uma barra verde a conquistar. Mas cada uma das três métricas é uma tradução numérica de um momento humano concreto: o segundo em que o conteúdo aparece, o instante em que o toque responde, a estabilidade que permite ler sem sobressaltos. Um blog que trata esses momentos com cuidado é um blog onde as pessoas ficam — e ficar é o pré-requisito de tudo o mais que você quer que aconteça, do anúncio visto à newsletter assinada. Otimizar Core Web Vitals é, no fundo, respeitar o tempo de quem veio ler.