SEO Técnico

Core Web Vitals: Guia Prático para Resultados Reais

O que aprendi otimizando centenas de sites — e como você pode aplicar hoje mesmo, com exemplos reais e código que funciona

Henrique Max

Especialista em SEO Técnico • Atualizado em 15 de abril, 2026 • 18 min de leitura

Não é só teoria

Veja como performance afeta seu negócio na prática

Neste guia você vai encontrar:

Por Que as Core Web Vitals Mudam o Jogo

Depois de mais de 5 anos otimizando sites de todos os tamanhos — desde lojas virtuais pequenas até portais com milhões de páginas — eu cheguei a uma conclusão simples: as Core Web Vitals são, acima de tudo, métricas de experiência humana. Elas traduzem, em números, como as pessoas sentem seu site.

Quando um site demora 4 segundos para mostrar uma imagem de produto, eu não vejo apenas um número ruim no relatório. Eu vejo um potencial cliente desistindo, fechando a aba e indo para o concorrente. Quando elementos pulam na tela durante a leitura, vejo frustração genuína — aquela que faz a pessoa desistir de comprar.

📌 O que mudou em 2024 e por que isso importa:

Desde março de 2024, o INP (Interaction to Next Paint) substituiu oficialmente o FID como métrica de responsividade. Isso significa que o Google agora olha para todas as interações durante uma visita, não apenas a primeira. Se antes dava para "mascarar" problemas de performance, agora não dá mais.

Muitas empresas que eu atendo ficaram perdidas com essa mudança. E com razão: entender o ciclo de renderização do navegador não é trivial. Mas as soluções, na maioria dos casos, são mais acessíveis do que parecem.

53%

dos usuários mobile abandonam sites que demoram mais de 3s para carregar

Fonte: Google Research, 2024

de atraso no tempo de carregamento pode reduzir conversões em até 7%

Fonte: Portent, 2024

2.5s

é o limite que separa uma experiência "boa" de uma "ruim" para o Google

Fonte: web.dev, 2024

Este conteúdo complementa o que já abordamos sobre rastreamento, indexação e ranqueamento. Performance não é só velocidade — é o que mantém seu conteúdo visível e relevante nos resultados de busca.

Entendendo o que Cada Métrica Realmente Significa

Antes de sair otimizando, é fundamental entender o que cada métrica representa. Não adianta decorar números — você precisa saber o que está acontecendo na prática quando cada uma delas está ruim.

LCP

Largest Contentful Paint

Meta: ≤ 2.500ms (2,5 segundos)

É o momento em que seu visitante pensa "ah, a página carregou". O maior elemento visível acima da dobra precisa aparecer rápido. Pode ser uma imagem, um bloco de texto ou um vídeo.

O que o Google mede: O tempo desde o início do carregamento até o maior elemento visível ser renderizado.

INP

Interaction to Next Paint

Meta: ≤ 200ms

É o tempo entre uma interação (clique, toque, tecla) e o navegador mostrar uma resposta visual. Se demora, o usuário acha que o site "travou" ou "não funcionou".

O que o Google mede: A pior interação (ou quase pior) durante toda a visita. Não é uma média!

CLS

Cumulative Layout Shift

Meta: ≤ 0,1

Mede o quanto os elementos visíveis se movem inesperadamente durante o carregamento. É sobre estabilidade visual — nada de coisas pulando ou mudando de lugar enquanto você tenta interagir.

O que o Google mede: A soma de todos os deslocamentos individuais. Cada vez que algo se move, a pontuação aumenta.

💡 Uma analogia que ajuda meus clientes a entenderem:

Pense no seu site como uma loja física. O LCP é o tempo que a vitrine demora para ficar visível. O INP é a rapidez com que o vendedor responde quando você pergunta algo. E o CLS é como se as prateleiras ficassem se mexendo enquanto você tenta pegar um produto.

Nenhum cliente gosta de uma loja assim, certo? O mesmo vale para o digital.

LCP

LCP: Fazendo o Conteúdo Principal Aparecer Imediatamente

O LCP é sobre a primeira impressão — e você só tem uma chance de causar uma boa impressão. Segundo a documentação oficial do web.dev, para oferecer uma boa experiência ao usuário, o LCP deve ocorrer em até 2,5 segundos. Mas na minha experiência, quanto mais próximo de 1,5s, melhor a taxa de conversão.

🔍 Os 3 problemas de LCP que mais encontro em sites brasileiros:

1. JavaScript bloqueando a renderização: Sites que dependem de JavaScript para mostrar a imagem principal. Enquanto o script carrega, compila e executa, o usuário vê uma tela branca. Isso acontece muito com sites feitos em React, Vue ou Angular sem SSR (Server-Side Rendering).

2. Fontes customizadas que seguram o texto: O texto está lá no HTML, pronto para ser exibido, mas não aparece porque a fonte web ainda não terminou de baixar. O navegador fica esperando, e o usuário vê uma tela sem texto.

3. Imagens não otimizadas e sem prioridade: A imagem principal (hero image) compete com dezenas de outros recursos pela largura de banda. Sem a devida priorização, ela carrega por último.

Estratégias que Realmente Funcionam:

1 Diga ao navegador o que é importante (Priority Hints)

O atributo fetchpriority é uma das adições mais úteis ao HTML moderno. Ele permite que você diga explicitamente ao navegador: "essa imagem aqui é a mais importante da página, carregue ela primeiro".

// ❌ Antes: sem prioridade definida
<img src="hero-banner.jpg" alt="Produto em destaque">

// ✅ Depois: alta prioridade para a imagem principal
<img fetchpriority="high" src="hero-banner.jpg" 
     alt="Produto em destaque" 
     width="1200" height="630"
     decoding="async">
                                

⚠️ Use com moderação: Reserve fetchpriority="high" para no máximo 2-3 imagens por página. Se tudo é prioritário, nada é prioritário. O navegador precisa saber o que carregar primeiro.

2 Faça pré-conexão com origens críticas

Se sua imagem principal está em um CDN ou domínio diferente, use preconnect para estabelecer a conexão antecipadamente. Isso pode economizar centenas de milissegundos.

// Adicione no <head> da sua página
<link rel="preconnect" href="https://cdn.seudominio.com">
<link rel="dns-prefetch" href="https://cdn.seudominio.com">
                                

O dns-prefetch resolve o DNS antecipadamente. O preconnect vai além: estabelece a conexão TCP e o handshake TLS. Use ambos para máxima performance.

3 Não espere pelo JavaScript para mostrar conteúdo

Se você usa React, Vue, Angular ou qualquer framework que renderiza no cliente (CSR), considere implementar Server-Side Rendering (SSR) ou Static Site Generation (SSG) pelo menos para o conteúdo acima da dobra.

🛠️ Solução pragmática: Mesmo que você não consiga migrar todo o site para SSR, você pode usar placeholder estático no HTML inicial. Envie a estrutura básica com um esqueleto (skeleton screen) e depois hidrate com JavaScript. O usuário vê algo imediatamente, e a percepção de velocidade melhora drasticamente.

4 Otimize o Critical Rendering Path

O caminho crítico de renderização é a sequência de passos que o navegador precisa executar para mostrar algo na tela. Reduza-o ao máximo:

Inline CSS crítico: O CSS necessário para o conteúdo acima da dobra deve estar inline no <head>, não em um arquivo externo
Adie CSS não crítico: Use media="print" onload="this.media='all'" para carregar CSS não essencial de forma assíncrona
Minimize e comprima: CSS e JavaScript minificados e servidos com Brotli ou Gzip

🧪 Laboratório Interativo: Veja a Diferença na Prática

Compare como pequenas mudanças afetam a percepção de velocidade:

⏱️ Tempo para ver conteúdo: 0ms

Ruim

> 4.0s

Melhorar

2.5s - 4.0s

Bom

≤ 2.5s

INP

INP: Quando o Site Responde aos Cliques (a Nova Métrica que Substituiu o FID)

O INP (Interaction to Next Paint) é a evolução do antigo FID. Enquanto o FID media apenas o atraso da primeira interação, o INP mede o tempo total entre qualquer interação e a próxima atualização visual — e considera a pior interação da visita (ou quase pior). Isso significa que se 99 cliques forem rápidos, mas 1 for lento, é esse 1 que define sua pontuação.

🔍 O que causa INP ruim na prática:

O problema mais comum que vejo é o JavaScript que faz coisas demais de uma vez quando o usuário interage. Cálculos complexos, manipulações pesadas do DOM, buscas síncronas — tudo empilhado na thread principal do navegador.

O navegador não consegue mostrar feedback visual enquanto está ocupado processando JavaScript. Para o usuário, parece que o site simplesmente "travou" ou "ignorou" o clique.

Como Melhorar sem Refazer Todo o Código:

1 Quebre tarefas longas (Yield to the Browser)

Tarefas que bloqueiam a thread principal por mais de 50ms são consideradas "longas" e prejudicam o INP. A solução é dividir o trabalho em pedaços menores, dando chance para o navegador processar eventos e renderizar frames entre eles.

// ❌ Antes: Uma função que bloqueia tudo por ~300ms
function processarTodosOsDados(dados) {
    dados.forEach(item => {
        // Processamento pesado aqui
        calcularAlgoComplexo(item);
        atualizarDOM(item);
    });
}

// ✅ Depois: Dividindo o trabalho com setTimeout
async function processarEmLotes(dados, tamanhoLote = 5) {
    for (let i = 0; i < dados.length; i += tamanhoLote) {
        const lote = dados.slice(i, i + tamanhoLote);
        lote.forEach(item => {
            calcularAlgoComplexo(item);
            atualizarDOM(item);
        });
        // Dá uma pausa para o navegador respirar
        await new Promise(resolve => setTimeout(resolve, 0));
    }
}
                                

🛠️ Dica prática: O scheduler.yield() é uma API mais moderna para isso, mas ainda não tem suporte universal. O setTimeout(resolve, 0) é a alternativa mais compatível atualmente.

2 Mova cálculos pesados para Web Workers

Web Workers permitem executar JavaScript em uma thread separada, sem bloquear a interface. São ideais para cálculos de frete, filtros complexos, processamento de dados e qualquer operação que demore mais de 50ms.

⚠️ Limitação importante: Web Workers não têm acesso ao DOM. Você precisa enviar os dados para o worker, processar, e receber o resultado de volta. Use a API postMessage para comunicação.

3 Feedback visual instantâneo é obrigatório

Mesmo que o processamento real vá demorar, você precisa mostrar algo imediatamente após o clique. Um spinner, um skeleton, uma mensagem — qualquer coisa que diga ao usuário "eu recebi seu comando e estou trabalhando nisso".

🚫 Nunca faça isso: Deixar o usuário sem nenhum feedback por mais de 100ms. O cérebro humano percebe delays acima desse limite, e a confiança começa a cair.

🧪 Laboratório Interativo: Teste Diferentes Cenários de INP

Cada botão simula um tipo de processamento após o clique:

⏱️ Tempo até feedback visual: 0ms

Área de feedback visual do clique

CLS

CLS: Acabando com os Elementos que Pulam na Tela

O CLS é minha métrica favorita para otimizar porque os resultados são imediatamente visíveis — literalmente. Layout estável significa usuários que conseguem ler sem interrupções, clicar no lugar certo e não se frustrar com movimentos inesperados.

🔍 Os vilões mais comuns do CLS:

1. Imagens sem dimensões definidas: O navegador não sabe quanto espaço reservar até a imagem carregar. Quando ela chega, empurra todo o conteúdo para baixo.

2. Anúncios e iframes que aparecem depois: Banners que são injetados dinamicamente e não têm espaço reservado.

3. Fontes web que causam FOIT/FOUT: Flash of Invisible Text ou Flash of Unstyled Text — a fonte demora para carregar e, quando chega, muda o layout do texto.

4. Conteúdo injetado dinamicamente acima do conteúdo existente: Como banners de promoção que aparecem no topo depois do carregamento.

Soluções Práticas e Definitivas:

1 Sempre defina dimensões para mídia

Esta é a causa número 1 de CLS que eu encontro. A solução moderna é usar aspect-ratio no CSS ou width e height no HTML.

// ✅ Método 1: HTML com width e height (o navegador calcula o aspect-ratio)
<img src="foto.jpg" alt="Descrição" 
     width="1200" height="630" 
     loading="lazy">

// ✅ Método 2: CSS com aspect-ratio (mais flexível)
.container-imagem {
    width: 100%;
    aspect-ratio: 16 / 9;
    background-color: #f0f0f0; /* placeholder visual */
}

// ✅ Método 3: Para vídeos e iframes responsivos
.video-wrapper {
    position: relative;
    width: 100%;
    aspect-ratio: 16 / 9;
}
.video-wrapper iframe {
    position: absolute;
    top: 0; left: 0;
    width: 100%; height: 100%;
}
                                

2 Reserve espaço para conteúdo dinâmico

Para anúncios, banners de cookie, formulários de newsletter — qualquer elemento que apareça após o carregamento inicial — reserve o espaço com min-height ou dimensões fixas.

🛠️ Para anúncios do Google AdSense: Use min-height no container do anúncio para reservar espaço mesmo quando o anúncio ainda não carregou. Isso previne que o conteúdo abaixo "pule" quando o banner aparecer.

3 Gerencie fontes com cuidado

Fontes customizadas são uma das principais causas de CLS. O texto renderiza com a fonte de fallback, depois muda para a fonte customizada — e o layout se ajusta.

// No seu @font-face ou na tag <link> da fonte
font-display: optional; // A fonte só aparece se carregar muito rápido

// Alternativa mais equilibrada:
font-display: swap; // Mostra a fonte de fallback primeiro, troca quando carregar

// Para máxima estabilidade, combine com size-adjust:
@font-face {
    font-family: 'MinhaFonte';
    src: url('/fonts/minhafonte.woff2') format('woff2');
    font-display: swap;
    size-adjust: 105%; // Ajusta o tamanho para minimizar a diferença
}
                                

🧪 Laboratório Interativo: CLS em Ação

Veja com seus próprios olhos como o layout se comporta:

📖 Área de leitura do usuário

Você está lendo este texto confortavelmente quando, de repente...

Este conteúdo abaixo também pode ser afetado se a imagem não tiver espaço reservado.

Ferramentas: O que Realmente Uso no Dia a Dia

Ferramentas demais confundem e paralisam. Depois de anos testando dezenas de opções, estas são as que realmente fazem parte do meu fluxo de trabalho diário:

Google Search Console

É gratuito e mostra como seus usuários reais estão experimentando seu site — dados de campo (field data), não de laboratório. O relatório de Core Web Vitals aqui é o que o Google efetivamente considera para ranqueamento.

Dica: Foque nas páginas com "URLs com problemas" primeiro. São elas que estão puxando sua pontuação para baixo.

Chrome DevTools

A guia Performance é essencial para depurar. Grave uma sessão de carregamento e interação, e veja exatamente o que está bloqueando a thread principal. A guia Lighthouse também dá boas recomendações, mas lembre-se: são dados de laboratório.

Dica: Use o "Performance Insights" (ícone de lâmpada) para uma análise mais amigável.

PageSpeed Insights

Combina dados de campo (quando disponíveis) com dados de laboratório. É o ponto de partida ideal para um diagnóstico rápido. Ele mostra separadamente a performance em mobile e desktop.

Dica: Sempre olhe a seção "Diagnostics" — ela lista problemas específicos e quantos ms você pode economizar.

Web Vitals Library

Para monitoramento contínuo, instale a biblioteca web-vitals no seu site. Ela coleta dados reais de todos os usuários e envia para o Google Analytics ou seu sistema de monitoramento.

Dica: Configure para enviar dados para o GA4. Assim você pode cruzar performance com taxas de conversão.

Meu fluxo de diagnóstico padrão:

1. Abro o Search Console para ver o quadro geral — quais grupos de páginas estão com problemas.

2. Para páginas problemáticas, uso o PageSpeed Insights para um diagnóstico rápido.

3. Se preciso entender exatamente o que está acontecendo, vou para o DevTools > Performance e gravo uma sessão.

Não preciso de 10 ferramentas diferentes. Essas três resolvem 95% dos casos que enfrento.

E se você está com problemas de indexação, já temos um guia específico para diagnosticá-los.

✅ Checklist de Ação: O que Fazer e em Que Ordem

Baseado no que funciona na prática e no retorno sobre esforço, aqui está minha recomendação de prioridade. Comece pelo que dá mais resultado com menos esforço.

🧠 Por que esta ordem?

Consertar CLS costuma ser rápido e os resultados são imediatos — é o "quick win". LCP pode exigir mais trabalho técnico, mas tem alto impacto. INP geralmente precisa de mudanças mais profundas no código, então demanda mais planejamento.

Comece pelo mais fácil, ganhe confiança e momentum, depois ataque os desafios mais complexos.

Prioridade	O que Fazer	Métrica	Esforço	Impacto	Prazo Sugerido
1	Definir width e height em TODAS as imagens	CLS	Baixo	Alto	Hoje
2	Adicionar fetchpriority="high" na imagem principal	LCP	Baixo	Alto	Hoje
3	Reservar espaço para banners e conteúdo dinâmico	CLS	Baixo	Alto	Esta semana
4	Pré-conectar a origens críticas (CDN, APIs)	LCP	Baixo	Médio	Esta semana
5	Dividir tarefas JavaScript longas (>50ms)	INP	Médio	Alto	Este mês
6	Implementar feedback visual instantâneo para interações	INP	Médio	Alto	Este mês
7	Mover cálculos pesados para Web Workers	INP	Alto	Alto	Planejar
8	Implementar SSR ou SSG para conteúdo crítico	LCP	Alto	Muito Alto	Planejar

🏆 A melhor estratégia: Não tente implementar tudo de uma vez. Muitos times se frustram e desistem porque querem resolver todos os problemas simultaneamente. Escolha 2-3 itens da lista, implemente, meça os resultados, e só então avance para os próximos.

Pequenas vitórias consistentes levam a grandes resultados. Este é o segredo que aprendi otimizando centenas de sites.

Para Terminar: Performance é Sobre Pessoas

Depois de mais de meia década trabalhando com Core Web Vitals, eu aprendi uma lição que vai além de qualquer métrica: otimização não é sobre agradar o Google. É sobre respeitar o tempo e a experiência das pessoas que visitam seu site.

Quando seu site carrega rápido, as pessoas ficam. Quando ele responde bem aos comandos, elas engajam. Quando o layout é estável e previsível, elas confiam. E quando tudo isso acontece junto, elas convertem — seja comprando, assinando, compartilhando ou voltando.

O Google criou as Core Web Vitals porque quer recompensar sites que oferecem boas experiências. Não é um castigo, é um incentivo. Seu trabalho, como profissional de SEO, desenvolvedor ou dono de negócio, é garantir que seu site seja um lugar onde as pessoas queiram estar.

Sobre o Autor

Sou Henrique Max, especialista em SEO Técnico com mais de 5 anos de experiência. Já otimizei centenas de sites, desde pequenos negócios locais até portais com milhões de visitas mensais. Acredito que a melhor forma de ensinar é mostrando como as coisas funcionam na prática, com exemplos reais e código que realmente roda.

Se você tiver dúvidas sobre Core Web Vitals ou quiser discutir um caso específico, me encontre nas redes sociais ou entre em contato pelo site.

APRENDA MAIS

Continue Aprendendo Sobre SEO Técnico

Mais conteúdos práticos baseados em experiência real

Ver todos os artigos de SEO Técnico

🍪 Uso de Cookies