SEO técnico
SEO técnico
Core Web Vitals: o que são LCP, INP e CLS e como melhorar cada um
Core Web Vitals são três métricas do Google medidas com usuários reais: LCP (o maior elemento visível carrega em até 2,5 s), INP (a página responde a cliques e toques em até 200 ms) e CLS (o conteúdo não se move mais que 0,1). A avaliação usa o percentil 75 dos visitantes. Para melhorar: servidor e imagem principal rápidos para o LCP, menos JavaScript de terceiros e tarefas longas para o INP, dimensões declaradas em imagens e espaço reservado para embeds para o CLS. Eles pesam pouco no ranking e muito na conversão.
Em resumo
- Limites de "bom": LCP até 2,5 s, INP até 200 ms, CLS até 0,1, medidos no percentil 75 de usuários reais.
- O INP substituiu o FID em março de 2024 e é a métrica em que mais sites falham hoje.
- Use o relatório do Search Console para achar os grupos de URLs com problema e o DevTools para encontrar a causa.
- LCP: servidor rápido e imagem principal com prioridade. INP: menos scripts de terceiros. CLS: dimensões declaradas.
- É um fator de desempate no ranking; o efeito na conversão é maior e mais direto.
O que são os Core Web Vitals e os limites atuais
Core Web Vitals são as três métricas que o Google usa para resumir a experiência de carregamento de uma página com dados de usuários reais. Cada uma mede uma coisa diferente, e o site precisa passar nas três para a página ser considerada boa.
| Métrica | O que mede | Bom | Precisa melhorar | Ruim |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Tempo até o maior elemento visível da tela (imagem, vídeo ou bloco de texto) terminar de renderizar | até 2,5 s | 2,5 s a 4 s | acima de 4 s |
| INP (Interaction to Next Paint) | Tempo entre uma interação (clique, toque, tecla) e a próxima atualização visível da tela, considerando a pior interação da visita | até 200 ms | 200 ms a 500 ms | acima de 500 ms |
| CLS (Cumulative Layout Shift) | Quanto o conteúdo se move na tela sem o usuário ter feito nada | até 0,1 | 0,1 a 0,25 | acima de 0,25 |
A avaliação é feita no percentil 75: 75% das visitas precisam ficar dentro do limite. Não basta a média ser boa; o que conta é a experiência dos visitantes mais lentos, que são justamente os de celular e rede móvel.
O INP substituiu o FID (First Input Delay) em 12 de março de 2024. O FID media apenas o atraso da primeira interação; o INP mede a resposta de todas as interações e reporta a pior. É por isso que muitos sites que passavam no FID passaram a falhar depois da troca.
Dados de campo e de laboratório: onde medir
Existem dois tipos de medição e confundi-los é a causa mais comum de diagnóstico errado:
- Campo (CrUX): dados coletados de usuários reais do Chrome que aceitaram compartilhar estatísticas. É o que o Google usa para o ranking e o que aparece no relatório Core Web Vitals do Search Console e na parte superior do PageSpeed Insights. Só existe para páginas com tráfego suficiente.
- Laboratório (Lighthouse): um teste simulado em um dispositivo e uma rede padronizados. Serve para diagnosticar e reproduzir problemas, mas não representa a base real de usuários. A nota de 0 a 100 do PageSpeed é de laboratório.
| Ferramenta | Tipo de dado | Para que serve |
|---|---|---|
| Search Console, relatório Core Web Vitals | Campo | Ver quais grupos de URLs falham, no celular e no desktop |
| PageSpeed Insights | Campo (topo) e laboratório (abaixo) | Ver o estado real de uma URL e as causas prováveis |
| Chrome DevTools, painel Performance | Laboratório, no seu computador | Encontrar a interação lenta e a tarefa longa que a causou |
| Extensão Web Vitals do Chrome | Campo, na sua sessão | Ver as métricas ao vivo enquanto navega |
| Biblioteca web-vitals + Analytics | Campo, dos seus usuários | Coletar as métricas de todos os visitantes e segmentar por página e dispositivo |
Comece sempre pelo relatório do Search Console: ele agrupa as URLs com o mesmo problema, e corrigir o template resolve o grupo inteiro.
Como melhorar o LCP
O LCP costuma ser uma imagem de destaque, um banner ou o título principal. As causas mais frequentes de LCP ruim, em ordem de impacto:
- Servidor lento (TTFB alto). Nada renderiza antes de o HTML chegar. Cache de página, CDN e hospedagem adequada resolvem a maior parte. Um TTFB acima de 800 ms já compromete o LCP sozinho.
- Imagem do LCP descoberta tarde. Imagens carregadas por CSS (background-image) ou por JavaScript só são encontradas depois de o navegador processar esses arquivos. Coloque a imagem principal no HTML com
<img>e sinalize a prioridade:fetchpriority="high". Nunca useloading="lazy"no elemento LCP. - Imagem pesada ou no formato errado. Sirva no tamanho exibido, em WebP ou AVIF, com
srcsetpara cada largura de tela. - Recursos que bloqueiam a renderização. CSS e JavaScript no
<head>atrasam tudo. Inline o CSS crítico, adie o restante e carregue scripts comdefer. - Fontes web. Se o LCP é um texto e a fonte demora, o texto só aparece depois. Use
font-display: swape façapreloaddas fontes principais.
Um exemplo de imagem principal preparada para o LCP:
<link rel="preload" as="image" href="/img/hero.webp" fetchpriority="high">
<img src="/img/hero.webp" width="1200" height="630" alt="..." fetchpriority="high" decoding="async">Como melhorar o INP
O INP é o mais difícil dos três, porque depende do que acontece durante toda a visita, e não só no carregamento. Ele piora quando a thread principal do navegador está ocupada no momento em que o usuário interage. As causas mais comuns:
- JavaScript de terceiros. Chats, pixels, mapas de calor, widgets de avaliação e scripts de tag manager competem pela thread principal. Cada um é pequeno; juntos são o problema. Audite o que está carregando e remova o que não gera decisão.
- Tarefas longas. Qualquer bloco de JavaScript acima de 50 ms bloqueia a resposta a cliques. Divida o trabalho em partes menores e devolva o controle ao navegador entre elas (
scheduler.yield()ousetTimeout). - Manipuladores de evento pesados. Um clique que dispara cálculo, renderização e envio de dados ao mesmo tempo demora a mostrar qualquer resposta. Atualize a tela primeiro e faça o resto depois.
- DOM muito grande. Páginas com dezenas de milhares de elementos fazem cada atualização de layout custar mais. Paginação, virtualização de listas e menos aninhamento ajudam.
- Hidratação de frameworks. Em sites feitos com React, Vue ou similares, a página pode parecer pronta e ainda não responder porque o JavaScript está "hidratando" os componentes. Renderização no servidor com hidratação parcial reduz o problema.
Para encontrar a interação lenta: no Chrome DevTools, grave a sessão no painel Performance, interaja com a página e procure as tarefas marcadas em vermelho. O painel mostra qual script estava rodando no momento do clique.
Como melhorar o CLS
O CLS é o mais fácil de corrigir, porque as causas são poucas e conhecidas:
- Imagens e vídeos sem dimensões. Sem
widtheheightno HTML, o navegador não reserva espaço e o conteúdo pula quando a mídia carrega. Declare sempre as dimensões ou useaspect-rationo CSS. - Anúncios, embeds e iframes. Reserve um espaço fixo para o contêiner antes de o conteúdo chegar.
- Fontes que trocam. A fonte de sistema é substituída pela fonte web e o texto muda de tamanho.
font-display: optionalou o ajuste de métricas comsize-adjustminimizam a troca. - Conteúdo injetado no topo. Banners de cookies, avisos e barras que aparecem depois do carregamento e empurram tudo para baixo. Posicione com
position: fixedou reserve o espaço. - Animações que mudam layout. Animar
top,heightoumarginprovoca deslocamento. Animartransformeopacitynão.
O CLS é medido durante toda a visita, incluindo as rolagens. Uma página estável no carregamento pode ter CLS ruim por um elemento que aparece no meio da leitura.
Quanto isso pesa no ranking
Os Core Web Vitals fazem parte dos sinais de experiência de página, e o Google é explícito ao dizer que são um fator de desempate entre páginas de conteúdo equivalente, não um fator dominante. Um site lento com o melhor conteúdo continua ganhando de um site rápido com conteúdo fraco.
Isso não os torna irrelevantes. Três razões para tratá-los com seriedade: em mercados disputados, o desempate decide posições; a Pesquisa e o Discover usam o desempenho como critério de elegibilidade para alguns recursos; e o efeito na conversão é direto e mensurável, independentemente do ranking. Uma loja com LCP de 5 segundos perde vendas em qualquer posição.
O erro oposto também existe: gastar meses otimizando vitals em um site que não ranqueia por falta de conteúdo ou por bloqueio de indexação. Nesse caso, o problema é outro, e é a primeira coisa que uma auditoria de SEO deve separar.
Checklist por plataforma
| Plataforma | Causa mais comum | Correção típica |
|---|---|---|
| WordPress | Excesso de plugins, tema pesado, sem cache | Cache de página, remover plugins redundantes, otimizar imagens, tema leve; avaliar hospedagem |
| Shopify e outras lojas SaaS | Apps que injetam scripts, temas com muitos recursos | Remover apps sem uso (eles deixam código), reduzir seções do tema, imagens no tamanho certo |
| Sites em React, Vue e Next | Hidratação pesada, bundles grandes, INP alto | Renderização no servidor, divisão de código, hidratação parcial, menos JavaScript no cliente |
| Site institucional estático | Imagens pesadas, fontes, scripts de terceiros | Formatos modernos, preload de fontes, carregar terceiros depois da interação |
| Qualquer plataforma | Tag manager com dezenas de tags | Auditoria das tags: cada uma precisa justificar a existência |
Se o site está passando por um redesign, é o momento certo de decidir essas coisas antes de construir, não de corrigir depois. É assim que tratamos o SEO técnico e a criação de sites: velocidade é requisito de projeto.