Core Web Vitals: O guia definitivo para otimizar a velocidade do seu site (LCP, FID, CLS)

📉 Core Web Vitals - A Nova Era do SEO: Por que velocidade agora é lei

Houve um tempo em que "SEO" significava apenas encher seu texto de palavras-chave e conseguir backlinks. O design ou a velocidade do site eram secundários. Esse tempo acabou.

Com a atualização de Page Experience, o Google mudou as regras do jogo. O algoritmo não lê mais o seu site como um robô frio; ele tenta "sentir" o site como um ser humano. Se o seu conteúdo é ótimo, mas a página demora 5 segundos para abrir ou os botões mudam de lugar sozinhos, o Google entende que a experiência é ruim e rebaixa seu posicionamento.

Os Três Pilares da Experiência

O Google resumiu a complexidade da performance web em três siglas essenciais, chamadas de Core Web Vitals (Sinais Vitais da Web). Cada uma mede um aspecto diferente da frustração do usuário:

• Carregamento (LCP): "Está demorando muito para aparecer algo útil na tela?"
• Interatividade (INP): "Eu clico no botão e o site trava ou não responde?"
• Estabilidade Visual (CLS): "O texto pulou para baixo enquanto eu estava lendo?"

Não é só sobre Ranking, é sobre Dinheiro

Estudos da Amazon, Google e Cloudflare mostram consistentemente o mesmo dado: cada 100ms de atraso custa 1% em vendas. Um site lento não apenas perde posições no Google; ele perde o cliente que já estava dentro da loja.

"O Core Web Vitals é a forma do Google dizer: 'Não me importo se o seu conteúdo é rei. Se o castelo (seu site) estiver desmoronando e for difícil de entrar, ninguém vai visitar o rei'."

⏱️ LCP (Largest Contentful Paint): A primeira impressão é a que fica

Esqueça o antigo conceito de "tempo total de carregamento". O usuário não se importa se o rodapé do site demorou para carregar; ele quer ver o conteúdo principal. O LCP mede exatamente isso: quanto tempo leva para o maior elemento visível (geralmente uma imagem de destaque ou um título H1) aparecer pronto na tela.

Qual é a meta?

Para passar no teste do Google, o LCP deve ocorrer em menos de 2,5 segundos. Entre 2,5s e 4,0s, você precisa de melhorias. Acima de 4,0s, seu site é considerado "pobre".

Os Grandes Vilões do LCP

Se o seu LCP está alto, o culpado quase sempre é um destes três:

1. Imagens Gigantes: Aquela foto linda no topo do site com 4MB de tamanho. O navegador precisa baixar tudo isso antes de "pintar" a tela.
2. Servidor Lento (TTFB alto): Se sua hospedagem demora 2 segundos só para "pensar" antes de enviar o primeiro byte, é matematicamente impossível atingir um LCP de 2,5s.
3. CSS e JS que Bloqueiam a Renderização: Scripts que obrigam o navegador a parar de desenhar o site para ler o código antes.

Como Resolver (O Básico)

• Otimize Imagens: Nunca use PNGs pesados para fotos. Converta para WebP ou AVIF e redimensione para o tamanho exato da tela.
• Lazy Loading Inteligente: Ative o carregamento lento (Lazy Load) para imagens que estão fora da tela, mas DESATIVE para a imagem de destaque (LCP). Se você aplicar Lazy Load na imagem principal, você piora o LCP!
• Melhore a Hospedagem: Servidores com cache bem configurado (como LiteSpeed ou NGINX) entregam o HTML inicial muito mais rápido.

"Dica de Ouro: Pré-carregamento (Preload). Se você sabe qual imagem será o LCP, use a tag <link rel='preload'> no cabeçalho do site para avisar ao navegador: 'Baixe isso primeiro, é prioridade!'."

🖱️ INP (Interaction to Next Paint): O fim do clique congelado

Você já clicou em um botão "Adicionar ao Carrinho" ou abriu um menu no celular e... nada aconteceu por meio segundo? Você clica de novo com raiva, achando que o toque não funcionou. Isso é uma falha de INP.

Em março de 2024, o Google substituiu o FID (First Input Delay) pelo INP (Interaction to Next Paint). Enquanto o FID media apenas o atraso do primeiro clique, o INP observa todas as interações durante a visita do usuário e avalia a pior delas. O objetivo é garantir que o site seja responsivo do início ao fim.

O que o INP realmente mede?

Ele cronometra o intervalo entre você fazer uma ação (clicar, tocar, digitar) e o navegador mostrar o resultado visual (o menu abrir, a cor do botão mudar, o item aparecer).

A meta é manter esse tempo abaixo de 200 milissegundos.

O Grande Vilão: A "Main Thread" Ocupada

Imagine que o navegador é um garçom (Main Thread). O trabalho dele é anotar seu pedido (clique) e servir a comida (pintar a tela). Se esse garçom também estiver ocupado lavando a louça e fazendo a contabilidade do restaurante ao mesmo tempo (executando Scripts pesados de JavaScript), ele vai ignorar seu chamado.

Sites com pontuação ruim de INP geralmente sofrem de:

• Excesso de JavaScript: Muitos scripts de rastreamento (pixels do Facebook, Analytics, Hotjar, Chatbots) rodando ao mesmo tempo.
• Tarefas Longas (Long Tasks): Um código mal otimizado que trava o navegador por mais de 50ms ininterruptos.
• DOM Gigantesco: Páginas com milhares de elementos HTML complexos que dificultam a atualização da tela.

"A Verdade Dura: Otimizar o INP é mais difícil que o LCP. Enquanto o LCP se resolve com cache e imagens leves, o INP exige que os desenvolvedores limpem e otimizem o código JavaScript. Menos plugins e temas mais leves são essenciais aqui."

🏗️ CLS (Cumulative Layout Shift): "Pare de mover meu botão!"

Não existe nada mais irritante na web: você vai clicar em um link ou botão e, milésimos de segundo antes do toque, uma imagem carrega no topo da página, empurra tudo para baixo e você clica no anúncio errado. Isso é um Layout Shift (Mudança de Layout).

O CLS mede a soma de todas essas mudanças inesperadas que ocorrem enquanto a página está aberta. Diferente das outras métricas, ele não é medido em tempo (segundos), mas em uma pontuação calculada baseada em quanto os elementos se moveram e quanto da tela foi afetada. A meta é ter uma pontuação abaixo de 0.1.

Os Criminosos da Instabilidade

O CLS acontece, basicamente, quando o navegador não sabe qual será o tamanho de um elemento antes de ele carregar. Ele desenha a página, e depois tem que "rearrumar a casa" quando o conteúdo chega.

1. Imagens sem dimensões: Se você coloca uma imagem <img> no HTML sem especificar width e height, o navegador acha que ela tem 0px de altura. Quando a imagem baixa, ele empurra o texto para abrir espaço.
2. Anúncios e Banners (Ads): Espaços publicitários que carregam dinamicamente costumam ser os maiores vilões.
3. Web Fonts: O texto carrega em uma fonte padrão (Times New Roman), e depois "pisca" para a fonte bonita do Google Fonts, mudando a largura das palavras e quebrando as linhas.

A Solução: Reserve o Lugar

Para zerar o CLS, você precisa dizer ao navegador quanto espaço reservar, mesmo que o conteúdo ainda não tenha chegado.

• Para Imagens: Sempre defina atributos de largura e altura. O CSS moderno usa isso para calcular a proporção (aspect-ratio) e deixar o espaço em branco reservado antes da imagem baixar.
• Para Anúncios: Envolva o anúncio em uma <div> com altura mínima (min-height). É melhor ter um espaço em branco momentâneo do que um layout que pula.

/* Exemplo de correção para CLS */
.anuncio-container {
    /* Reserva o espaço antes do script do anúncio carregar */
    min-height: 250px; 
    background-color: #f0f0f0;
}

img {
    /* Garante que a imagem respeite a proporção reservada */
    height: auto;
    width: 100%;
}

"Regra de Ouro: Nunca insira conteúdo acima de um conteúdo existente, a menos que seja em resposta a uma interação do usuário (como abrir um menu acordeão). Se o conteúdo entra sozinho e empurra o resto, o Google penaliza."

🩺 Diagnóstico Preciso: A diferença entre Lab Data e Field Data

Uma situação clássica frustra milhares de donos de sites: você roda um teste no Lighthouse do seu navegador e recebe uma nota 95 (Verde). Feliz, você vai ao Google Search Console e vê que suas URLs estão marcadas como "Pobres" (Vermelho). Como isso é possível?

A resposta está na origem dos dados. O Google utiliza duas fontes distintas de informação:

1. Lab Data (Dados de Laboratório)

É o teste sintético. Quando você clica em "Analisar" no PageSpeed Insights ou roda o Lighthouse no seu computador:

• O teste simula um dispositivo específico (ex: Moto G4) em uma rede específica (ex: 4G lento).
• É um ambiente controlado e consistente.
• Para que serve: Ótimo para debugging. Se você mudar uma linha de código, o Lab Data mostra imediatamente se melhorou ou piorou.
• O Perigo: Ele não reflete a realidade. Se o seu computador é rápido, o teste pode mascarar problemas que um celular barato sofreria.

2. Field Data (Dados de Campo / RUM)

É a realidade nua e crua. O Google coleta dados anonimizados de usuários reais que usam o navegador Chrome (através do relatório CrUX - Chrome User Experience Report).

• Reflete o que seus visitantes reais estão vivenciando (suas conexões de internet reais, seus celulares velhos ou novos).
• Para que serve: É o único dado que importa para o Ranking. O Google usa essa média dos últimos 28 dias para decidir se seu site sobe ou desce nas pesquisas.
• O Problema: Demora para atualizar. Se você corrigir o site hoje, o Field Data pode levar até um mês para ficar verde, pois ele precisa coletar novos acessos para diluir a média ruim antiga.

"Resumo da Ópera: O Lab Data é o exame que você faz em casa para treinar. O Field Data é o resultado do campeonato. Você pode tirar 100 no treino (Lab), mas se no dia do jogo (Field) a internet do seu usuário falhar, o Google registra a falha."

🛠️ Otimização Prática: O caminho para o "Semáforo Verde"

Agora que você entende o diagnóstico, como curar o paciente? Embora otimizar performance possa se tornar algo extremamente técnico, 80% dos problemas de Core Web Vitals são resolvidos com um checklist básico de infraestrutura e boas práticas.

1. Otimização de Imagens (O básico obrigatório)

Nenhuma imagem no seu site deve estar em formato PNG ou JPEG antigo, e nenhuma deve pesar mais que 100kb (exceto banners muito grandes). Use ferramentas ou plugins para converter tudo automaticamente para WebP ou AVIF, formatos que mantêm a qualidade com metade do peso.

2. Cache é Vida

Sem cache, seu servidor tem que montar o quebra-cabeça do site toda vez que alguém entra. Com cache, ele entrega uma "foto" pronta do site montado. Isso reduz o tempo de resposta (TTFB) drasticamente e melhora o LCP. Plugins de cache (como o WP Rocket ou W3 Total Cache) são obrigatórios em plataformas como WordPress.

3. Use uma CDN (Content Delivery Network)

Se seu servidor está em São Paulo e um usuário acessa de Lisboa, a luz leva um tempo para viajar. Uma CDN (como a Cloudflare) guarda cópias das suas imagens e arquivos em servidores espalhados pelo mundo. O usuário baixa o conteúdo do servidor mais perto da casa dele.

4. Minificação e Adiamento (Defer)

Computadores leem código sem espaços e comentários. "Minificar" o CSS e JS remove espaços em branco inúteis, diminuindo o tamanho dos arquivos. Além disso, configurar scripts não essenciais para carregar com o atributo defer ou async libera o navegador para desenhar a tela (LCP/INP) antes de processar o resto.

"A melhor otimização é aquela que você não precisa fazer: Remova o que não usa. Desative plugins inúteis, remova fontes que não estão no design e limpe o banco de dados. Um site leve é, por natureza, um site rápido."

💡 Minhas indicações pra você

📚 Leitura complementar:
• Web Performance Is User Experience - Denis Real (Artigo clássico sobre a psicologia da espera)

🔍 4 Segredos: Quer a melhor performance e retorno do seu site?
✔ A melhor Hospedagem e Revenda de Hospedagem no Brasil: Cloudx
✔ Otimização completa para seu site virar um foguete: WP Rocket
✔ Você não aparece sem um SEO de qualidade. Use o melhor: YTI&W Auto LLM SEO!
✔ Automatize o marketing, capture leads e muito mais: RD Station

Dúvidas ou sugestões? Participe nos comentários, abaixo.