Core Web Vitals: o que realmente move o ponteiro

Core Web Vitals é o conjunto de métricas que o Google usa para medir a experiência de carregamento de uma página. Virou tema obrigatório em auditoria de SEO, e é onde muita equipe gasta semanas com retorno próximo de zero.

O motivo é uma confusão de proporção. Velocidade importa, e importa muito menos que conteúdo relevante. Um site com problema de indexação ou com páginas que não respondem à busca não melhora nada otimizando de dois segundos para 1,7.

Este artigo é sobre as poucas correções que de fato movem o ponteiro, e sobre saber quando parar.

As três métricas, em linguagem direta

Tempo até o maior elemento aparecer

Mede quanto tempo leva até o principal bloco visual da página ficar visível. Em quase todo site B2B, esse elemento é a imagem do topo ou o bloco de texto principal.

É a métrica que mais falha e a que mais tem correção óbvia. Também é a que melhor corresponde à percepção real do visitante — "o site demorou" quase sempre significa que esse número está alto.

Estabilidade visual

Mede o quanto o conteúdo se move enquanto a página carrega. Todo mundo já viveu isso: você vai clicar em um link, uma imagem carrega acima dele, o conteúdo desce, e você clica em outra coisa.

É a métrica mais fácil de zerar e a mais negligenciada, porque a causa quase sempre é a mesma e é trivial.

Responsividade à interação

Mede quanto tempo a página leva para responder quando alguém clica, toca ou digita. Falha quando há JavaScript pesado ocupando o processamento.

Em site de conteúdo, costuma estar bem por natureza — a menos que haja excesso de script de terceiro.

Diagnosticando qual é o gargalo

Antes de corrigir, é preciso saber o que está segurando. O painel de rede do navegador responde em dez minutos, e a leitura é mais simples do que parece.

Abrindo o painel

Nas ferramentas de desenvolvedor, aba de rede, com o cache desativado e a simulação de conexão móvel ligada. Recarregue e observe a linha do tempo.

O que procurar, em ordem

Qual é o maior arquivo? Ordene por tamanho. Se o primeiro item tem centenas de kilobytes e é uma imagem, você já achou.

Quantos domínios diferentes? Cada um custa uma conexão nova. Em site de conteúdo, mais de três ou quatro é sinal de excesso de terceiro.

O que bloqueia a renderização? Arquivos de estilo e script no topo do documento impedem a página de aparecer até serem baixados. Se há vários, o texto fica esperando.

Há um vão na linha do tempo? Um intervalo em que nada acontece indica espera — normalmente do servidor respondendo, ou de um script que precisa executar antes de o próximo recurso ser solicitado.

Traduzindo o que você viu

Em site de conteúdo estático, as duas primeiras linhas explicam a grande maioria dos casos.

Corrigindo o tempo de carregamento, em ordem

Cinco correções cobrem a maior parte dos casos em site de conteúdo.

1. Servir a imagem principal do próprio domínio

Hotlinkar imagem de banco de imagens é comum e problemático: o elemento que define a métrica passa a depender da velocidade de um servidor que você não controla e não pode otimizar.

Além disso, adiciona uma conexão nova — resolução de DNS, handshake — antes de o download começar. Em conexão móvel, isso sozinho custa centenas de milissegundos.

2. Nunca aplicar carregamento tardio na imagem do topo

O erro mais comum e o mais fácil de corrigir. A recomendação genérica "use lazy loading em todas as imagens" é aplicada literalmente, incluindo a imagem que define a métrica — e o resultado é adiar exatamente o que deveria ser priorizado.

A regra: a imagem visível ao abrir a página recebe prioridade alta e nunca carregamento tardio. As de baixo da dobra, o inverso.

3. Declarar largura e altura em todas as imagens

Isso resolve a estabilidade visual quase por completo, e é uma linha por imagem. Sem as dimensões, o navegador não sabe quanto espaço reservar e o conteúdo salta quando a imagem chega.

Vale conferir que os números declarados correspondem à imagem real. Declarar 1400 por 933 numa imagem de 1200 por 630 causa distorção — e é um erro que passa despercebido quando a imagem é trocada e o HTML não.

4. Externalizar o CSS

Estilo embutido em cada página não pode ser cacheado entre páginas. O visitante baixa o mesmo conteúdo a cada clique.

Em um site com cem páginas carregando onze mil caracteres de CSS embutido, isso é cerca de um megabyte de conteúdo idêntico replicado — e a segunda página visitada carrega tão devagar quanto a primeira.

5. Remover script de terceiro abandonado

Ferramentas de análise que ninguém abre, chat que foi desativado no painel mas continua carregando, pixel de campanha encerrada. Cada um adiciona conexão e processamento.

Um inventário simples: abra o painel de rede do navegador, liste os domínios externos que a página consulta, e pergunte a alguém para que serve cada um. A resposta para dois ou três costuma ser "não sei".

Uma observação sobre a ordem dessa lista: ela é deliberadamente diferente da que ferramentas de auditoria produzem. Relatórios automatizados tendem a listar dezenas de sugestões ordenadas por impacto teórico calculado sobre a página isolada — "elimine recursos que bloqueiam a renderização", "reduza JavaScript não utilizado". Muitas dessas exigem mudança de arquitetura e rendem pouco em site de conteúdo estático. As cinco acima cobrem a maior parte do ganho disponível e nenhuma exige mais que algumas horas.

Estabilidade visual: as quatro causas

É a métrica mais fácil de zerar e a que mais irrita quem usa o site. Quatro causas cobrem praticamente tudo.

Imagem sem dimensão declarada. A causa dominante. Sem largura e altura no HTML, o navegador reserva zero espaço e o conteúdo salta quando a imagem chega. Uma linha por imagem resolve.

Conteúdo inserido por JavaScript acima do que já está visível. Banner de cookies, aviso no topo, bloco de recomendação. Se ele aparece depois e empurra tudo para baixo, causa deslocamento. A correção é reservar o espaço antes, mesmo vazio.

Fonte que troca depois de carregar. O texto aparece com a fonte do sistema e é substituído pela fonte externa, que tem métricas diferentes — e as linhas se reorganizam. Usar fonte do sistema elimina o problema; se não for possível, vale ajustar as métricas de fallback para que o espaço ocupado seja parecido.

Elemento incorporado sem altura fixa. Vídeo, mapa, formulário externo. O espaço só é definido quando o conteúdo carrega. Reservar a altura por CSS resolve.

Um teste rápido sem ferramenta: recarregue a página com a conexão limitada e observe. Se algo pula, você viu a causa.

Sobre o peso das imagens

Imagem costuma ser 60% ou mais do peso de uma página de conteúdo. Três decisões resolvem a maior parte.

Formato. Formatos modernos entregam qualidade equivalente com 25% a 35% menos bytes que JPEG. A conversão é mecânica e vale para todo o acervo.

Dimensão real. Servir uma imagem de 3000 pixels de largura numa área que exibe 720 é desperdício puro. Redimensione para o tamanho máximo em que ela será exibida.

Necessidade. A pergunta que ninguém faz: essa imagem precisa existir? Uma foto genérica de banco de imagens no topo de um artigo não informa nada, custa centenas de kilobytes e é o elemento que define a métrica.

Uma alternativa que resolve os três de uma vez: capas geradas localmente, tipográficas, com o título do artigo. Pesam uma fração de uma foto, não dependem de domínio externo, e comunicam mais que uma imagem de reunião corporativa que não tem relação com o texto.

O que depende do servidor, não do código

Uma parte da velocidade não está no HTML e sim na configuração de hospedagem. Três itens que rendem e costumam estar desligados.

Compressão. Texto — HTML, CSS, JavaScript, XML — comprime em cerca de 70%. Se a compressão não está ativa, você está enviando três vezes mais bytes do que precisa em todo arquivo de texto do site. É uma configuração de poucas linhas.

Cache no navegador. Sem instrução de cache, o visitante rebaixa a folha de estilo e as imagens em cada página que abre. Com cache de longa duração para recursos que não mudam, a segunda página carrega quase instantaneamente.

Um cuidado: cache longo em arquivo que muda causa o problema oposto — o visitante fica com a versão antiga. A prática usual é incluir uma versão no nome do arquivo quando ele é alterado.

Tempo de resposta do servidor. Antes de qualquer arquivo ser baixado, o servidor precisa responder. Em hospedagem compartilhada barata, esse tempo sozinho pode consumir boa parte do orçamento de carregamento — e nenhuma otimização de imagem compensa.

Como saber se é o caso: no painel de rede, olhe o tempo de espera do primeiro documento. Se ele passa de meio segundo consistentemente em um site estático, o problema é a hospedagem, não a página.

Quando parar de otimizar

Esta é a parte que falta na maioria dos guias.

O ganho de otimização é fortemente decrescente. Sair de doze segundos para três muda a experiência inteira e o comportamento do visitante. Sair de dois segundos para 1,7 não muda nada perceptível, e pode custar semanas.

Três critérios para decidir onde parar:

Passou do limiar recomendado? Se as três métricas estão na faixa boa para a maioria dos visitantes reais, o trabalho está feito. Perseguir nota máxima em ferramenta de teste é otimizar para o instrumento, não para a pessoa.

O gargalo real é esse? Se o site tem problema de indexação, conteúdo raso ou nenhuma página de fundo de funil, velocidade não é o que está segurando o resultado.

O custo da próxima correção é proporcional? Trocar formato de imagem custa horas. Reescrever a arquitetura de renderização custa meses. A segunda só se justifica se a primeira não resolveu.

O que velocidade não resolve

Vale ser explícito, porque muita auditoria vende otimização como solução geral.

Velocidade é um desempate. Entre duas páginas igualmente relevantes, a mais rápida tende a levar vantagem. Entre uma página rápida e vazia e uma lenta e excelente, a segunda ganha — porque relevância pesa muito mais.

Isso significa que otimizar Core Web Vitals em um site com conteúdo fraco produz um site rápido que continua não ranqueando. É um resultado frustrante e previsível, e acontece com frequência porque velocidade é mensurável e conteúdo não é.

O efeito real de velocidade aparece em outro lugar, e é maior do que o de ranqueamento: taxa de abandono. Visitante que espera demais volta para a busca antes de ver o conteúdo. Em site B2B, onde cada visita qualificada é cara, isso importa independentemente de posição.

O que esperar do ganho

Uma calibragem que evita frustração e evita também gastar demais.

Sobre posição na busca. Velocidade é um fator entre muitos, e de peso modesto. Corrigir Core Web Vitals raramente produz um salto visível de ranqueamento sozinho. O que ele faz é remover uma desvantagem — se as suas páginas eram mais lentas que as concorrentes, você deixa de perder por isso.

Isso significa que o efeito é maior em mercado onde os concorrentes já são rápidos, e menor onde todo mundo é lento.

Sobre comportamento do visitante. Aqui o efeito é maior e mais imediato. Reduzir de oito segundos para três muda a taxa de abandono de forma perceptível, e isso aparece no analytics em semanas — bem antes de qualquer efeito de busca.

Em site B2B, onde cada visita qualificada custa caro para conquistar, perder o visitante antes de ele ver o conteúdo é o desperdício mais direto que existe.

Sobre o prazo dos dados. O relatório de campo do Search Console usa uma janela móvel de 28 dias. Depois de uma correção, o número só reflete a melhora completa quase um mês depois — e vai melhorar gradualmente durante esse período. Medir na semana seguinte e concluir que não funcionou é o erro previsível.

Medindo do jeito certo

Três armadilhas comuns na medição.

Testar sempre a home. A home costuma ser a página mais leve e a menos importante para busca. Teste as páginas de conteúdo que recebem tráfego real.

Testar em desktop. A maior parte do tráfego é móvel, e é lá que os problemas aparecem. Se você só olha a versão de computador, está medindo o cenário fácil.

Confundir teste pontual com dado de campo. Uma ferramenta de teste simula uma visita em condições controladas. O Search Console mostra o que aconteceu com visitantes reais, em conexões e aparelhos reais. Para diagnosticar, use o segundo; para depurar uma correção específica, o primeiro.

Uma rotina que basta: abrir o relatório de experiência no Search Console uma vez por mês e ver se alguma URL saiu da faixa boa. Se nada mudou, não há o que fazer.

O caso específico do celular

Quase todo problema de velocidade é um problema de celular. Três razões que se acumulam: conexão mais instável, processador mais lento para executar JavaScript, e tela menor que exige imagem proporcionalmente maior em relação ao conteúdo visível.

Duas correções específicas que valem em site B2B:

Servir imagem menor para tela menor. A mesma imagem de 1200 pixels não precisa ir para um aparelho que exibe 380. Servir versões por tamanho de tela corta o peso pela metade em móvel.

Cuidado com fonte externa. Carregar tipografia de um domínio de terceiro adiciona uma conexão e frequentemente causa um período em que o texto fica invisível esperando a fonte. Fontes do sistema carregam instantaneamente e, em conteúdo técnico, a diferença visual é pequena diante do custo.

Um roteiro de meio dia

1. Abra o Search Console e veja quais URLs estão fora da faixa boa, em móvel. Se nenhuma estiver, pare aqui — o trabalho é outro.
2. Pegue a URL mais importante entre as que falham e identifique qual é o elemento que define o tempo de carregamento. Costuma ser a imagem do topo.
3. Verifique se ela é hotlinkada, tem carregamento tardio, ou está superdimensionada. As três causas cobrem a maioria dos casos.
4. Declare largura e altura em todas as imagens do template. Resolve a estabilidade visual de uma vez.
5. Liste os domínios externos que a página consulta e remova os que ninguém usa.
6. Externalize o CSS se ele estiver embutido em cada página.
7. Reveja em quatro semanas, com dado de campo. Ferramenta de teste responde na hora; o dado real leva tempo para acumular.

Meio dia resolve a maior parte do que dá para resolver em site de conteúdo. O que sobra depois disso costuma exigir mudança de arquitetura, e essa decisão deveria competir com todas as outras coisas que a equipe poderia estar fazendo — não ser automática por aparecer em vermelho numa ferramenta.