Se voce acompanha o universo de SEO e desenvolvimento web, certamente ja ouviu falar de Core Web Vitals. Desde junho de 2021, o Google utiliza essas metricas como sinal de ranqueamento oficial. Mas o que exatamente sao esses indicadores, como eles sao calculados e, principalmente, como garantir que seu site tenha notas maximas? Neste artigo voce vai entender tudo em detalhe tecnico.
Um site com boas notas em Core Web Vitals pode ter ate 30% mais conversoes. Velocidade nao e so SEO e experiencia do usuario e taxa de conversao.
O que sao Core Web Vitals?
Core Web Vitals sao um conjunto de metricas criadas pelo Google para quantificar a experiencia do usuario na web. Elas medem tres aspectos fundamentais: carregamento, interatividade e estabilidade visual. Diferente de metricas tradicionais como "tempo de carregamento total", os Core Web Vitals focam no que o usuario realmente percebe ao navegar.
Essas metricas fazem parte dos Web Vitals, uma iniciativa maior do Google para unificar a medicao de qualidade de experiencia em unico conjunto de indicadores padronizados. Os Core Web Vitals sao o subconjunto mais critico desse grupo.
As tres metricas fundamentais
LCP – Largest Contentful Paint
O LCP mede o tempo que leva para o maior elemento visivel da pagina ser renderizado. Isso pode ser uma imagem, um video, um bloco de texto grande ou um elemento de fundo. O LCP e crucial porque representa o momento em que o usuario percebe que a pagina realmente carregou.
- Bom: inferior a 2,5 segundos
- Precisa melhorar: entre 2,5 e 4,0 segundos
- Ruim: superior a 4,0 segundos
O LCP considera apenas o viewport inicial (acima da dobra). Elementos que aparecem conforme o usuario rola a pagina nao contam para essa metrica. O calculo e feito pelo Performance API do navegador, que identifica automaticamente o maior elemento visivel a cada frame e reporta o tempo do maior elemento encontrado durante o carregamento.
INP – Interaction to Next Paint
O INP substituiu o FID (First Input Delay) em marco de 2024 como metrica oficial. Enquanto o FID media apenas o delay inicial da primeira interacao, o INP avalia a latencia total de todas as interacoes do usuario ao longo de toda a visita. Isso inclui cliques, toques e teclas.
- Bom: inferior a 200 milissegundos
- Precisa melhorar: entre 200 e 500 ms
- Ruim: superior a 500 ms
O INP captura o tempo desde que o usuario inicia uma interacao (exemplo: um clique) ate o momento em que o navegador consegue pintar o proximo frame com o resultado visual dessa interacao. Se o JavaScript esta ocupado processando tarefas longas (>50 ms), o navegador nao consegue responder rapidamente, resultando em INP alto.
CLS – Cumulative Layout Shift
O CLS mede a estabilidade visual da pagina. Ele quantifica o quanto os elementos da pagina se deslocam inesperadamente durante o carregamento. Um CLS alto significa que o usuario experimentou "pulos" no conteudo — algo extremamente frustrante, especialmente ao tentar clicar em algo.
- Bom: inferior a 0,1
- Precisa melhorar: entre 0,1 e 0,25
- Ruim: superior a 0,25
O calculo do CLS leva em conta dois fatores: a fracao de impacto (quanto da tela foi deslocada) e a fracao de distancia (quanto os elementos se moveram). Pontos de layout shift sao registrados sempre que um elemento visivel muda de posicao entre dois frames consecutivos, exceto quando a mudanca e iniciada por uma acao do usuario (como um toque ou scroll).
Como os Core Web Vitals sao medidos?
Existem duas categorias de medicao: dados de campo e dados de laboratorio. Entender a diferenca entre elas e fundamental para diagnosticar corretamente os problemas.
Dados de campo (field data ou RUM)
Os dados de campo sao coletados de usuarios reais que visitam seu site. O Google obtem esses dados atraves do Chrome User Experience Report (CrUX), que agrega metricas anonimas de milhoes de usuarios do Chrome. Esses dados refletem as condicoes reais de rede, dispositivo e localizacao geografica. As ferramentas que usam dados de campo incluem:
- PageSpeed Insights – mostra dados CrUX dos ultimos 28 dias
- Search Console – relatorio de Core Web Vitals por URL
- Chrome DevTools – painel Web Vitals com dados de campo
- Lighthouse na versao de fluxo de usuario – simulacao com dados reais
Dados de laboratorio (lab data)
Os dados de laboratorio sao coletados em ambiente controlado, simulando uma conexao de rede e dispositivo especificos. Ferramentas como Lighthouse, PageSpeed Insights (na aba de laboratorio) e WebPageTest geram esses dados. Eles sao uteis para debugging e reproducao de problemas, mas podem nao refletir a experiencia real de usuarios em dispositivos lentos ou redes congestionadas.
Dica: Sempre compare os dados de campo com os de laboratorio. Um Lighthouse com nota 100 pode nao significar nada se o CrUX mostrar LCP acima de 4 segundos para usuarios reais. O dado de campo e o que o Google usa para ranqueamento.
Por que o Google se importa com Core Web Vitals?
A resposta e simples: experiencia do usuario. Estudos do proprio Google mostram que:
- 53% dos usuarios abandonam um site que leva mais de 3 segundos para carregar
- Sites com bom desempenho tem taxa de rejeicao ate 32% menor
- Um atraso de 1 segundo no carregamento reduz a satisfacao do usuario em 16%
- A cada 100ms de melhora no LCP, a conversao aumenta em ate 1%
Desde junho de 2021, o Google incorporou os Core Web Vitals como sinal de ranqueamento oficial. Isso significa que, entre duas paginas com conteudo similar e backlinks equivalentes, aquela com melhores metricas de CWV tende a ranquear melhor. E importante notar que o impacto e maior em paginas de noticias e blogs, onde a experiencia do usuario e particularmente valorizada pelo algoritmo.
O peso dos Core Web Vitals no algoritmo e comparavel ao de outros sinais de experiencia de pagina, como compatibilidade com dispositivos moveis, navegacao segura (HTTPS) e ausencia de intersticiais intrusivos. Eles nao substituem a relevancia do conteudo, mas sao um diferencial competitivo importante em nichos com alta concorrencia.
Problemas comuns que afetam cada metrica
O que causa LCP alto?
O LCP pode ser prejudicado por varios fatores tecnicos. Os mais comuns sao:
- Imagens muito grandes ou nao otimizadas: imagens de 4000x3000px servidas sem redimensionamento ou compressao
- Tempo de resposta do servidor lento (TTFB alto): o servidor demora mais de 600ms para comecar a responder
- Recursos de renderizacao bloqueante: arquivos CSS e JavaScript que bloqueiam a renderizacao do conteudo principal
- Web fonts lentos: fontes personalizadas que causam FOIT (Flash of Invisible Text) atrasam a renderizacao do texto
- Renderização do lado do cliente: frameworks JavaScript que so exibem conteudo apos processar e baixar bundles grandes
O que causa INP alto?
O INP e diretamente afetado pela capacidade de resposta do JavaScript no navegador:
- JavaScript pesado e nao otimizado: bibliotecas gigantes, polifills desnecessarios e codigo inchado
- Long Tasks (tarefas que excedem 50ms): o navegador fica "travado" enquanto processa scripts no thread principal
- Event handlers ineficientes: listeners de eventos que realizam calculos pesados ou manipulam extensivamente o DOM
- Third-party scripts: analytics, mapas, widgets de redes sociais que competem pelo thread principal
- Garbage Collection frequente: alocacao excessiva de objetos causa pausas frequentes do coletor de lixo
O que causa CLS alto?
O CLS e resultado de mudancas inesperadas no layout apos a pagina ja ter sido pintada:
- Imagens sem atributos de dimensao (width/height): o navegador nao reserva espaco e o layout "pula" quando a imagem carrega
- Insercao dinâmica de conteudo: anuncios, banners de cookies ou embeds que aparecem apos o carregamento inicial
- Anuncios sem espaco reservado: ads que empurram o conteudo para baixo ao serem carregados
- Web fonts causando FOIT/FOUT: fallback de fontes com tamanhos drasticamente diferentes causam reflow
- Animações e transicoes CSS que afetam layout: animar propriedades como
width,heightoumarginem vez detransform
Como otimizar cada metrica na pratica
Otimizacao de LCP
- Comprima e redimensione imagens: converta para WebP, redimensione para o tamanho maximo de exibicao e aplique compressao lossy de qualidade 80-85
- Habilite compressao no servidor: use
Brotli(mais eficiente que gzip) para comprimir HTML, CSS e JS - Reduza o tempo de resposta do servidor: otimize consultas a banco de dados, implemente cache de pagina e use um provedor de hospedagem rapido
- Preload do hero image ou LCP candidate: use
<link rel="preload" href="hero.webp" as="image"> - Minimize CSS e JavaScript bloqueante: inlineie o CSS critico e adie scripts com
deferouasync - Use font-display: swap: evite FOIT usando
font-display: swapno CSS para que o texto seja exibido com fonte fallback imediatamente
Otimizacao de INP
- Divida tarefas longas: use
setTimeout(),requestIdleCallback()ouscheduler.postTask()para quebrar scripts grandes em microtarefas - Remova JavaScript nao utilizado: ferramentas como o coverage tab do DevTools ajudam a identificar codigo morto
- Adie third-party scripts: carregue scripts de terceiros com
asyncoudefere priorize o thread principal para interacoes do usuario - Use Web Workers: descarregue processamento pesado (analytics, criptografia) para threads separadas
- Implemente debouncing e throttling: evite que eventos como scroll e resize disparem handlers excessivamente
- Prefira
content-visibility: auto: essa propriedade CSS adia a renderizacao de elementos fora da tela, liberando o thread principal
Otimizacao de CLS
- Sempre defina width e height em imagens: mesmo em imagens responsivas, use
width: 100%; height: auto; aspect-ratio: 16/9para manter a proporcao - Reserve espaco para anuncios e embeds: defina um container com altura minima
min-heightpara elementos carregados dinamicamente - Evite injetar conteudo acima do fold: todo conteudo no topo da pagina deve estar presente no HTML inicial, sem depender de JavaScript
- Use
font-display: optionalouswap: fontes comoptionalso sao usadas se ja estiverem em cache, eliminando reflow - Prefira
transformeopacitypara animacoes: essas propriedades nao disparam layout nem paint, apenas composicao
Ferramentas para monitorar Core Web Vitals
Nao basta otimizar uma vez e esquecer. Core Web Vitals exigem monitoramento continuo. Aqui estao as principais ferramentas:
- PageSpeed Insights – combina dados de campo (CrUX) e laboratorio (Lighthouse) em unico relatorio
- Google Search Console – relatorio especifico de Core Web Vitals por grupo de URLs
- Lighthouse (Chrome DevTools) – auditoria local detalhada com recomendacoes de melhoria
- Web Vitals Extension – extensao do Chrome que mostra LCP, INP e CLS em tempo real enquanto voce navega
- CrUX Dashboard (Looker Studio) – dashboard personalizado com dados historicos do Chrome UX Report
- WebPageTest – analise avancada com filmstrip, grafico de agua e metricas detalhadas
- Speedcurve, Calibre, Request Metrics – ferramentas de RUM (Real User Monitoring) para monitoramento continuo
Por que sites da CloudBird se destacam nos Core Web Vitals?
Nosso processo de desenvolvimento e pensado para performance desde o primeiro byte. Todos os sites que entregamos sao codificados a mao em HTML e CSS puros, sem frameworks pesados como React, Angular ou Vue na camada de apresentacao. Isso elimina quilobytes de JavaScript desnecessario que compete pelo thread principal com as interacoes do usuario.
Nossas praticas incluem: imagens automaticamente convertidas para WebP, preconnect para Google Fonts e CDN, CSS critico inlineado, lazy loading nativo, atributos de dimensao em todas as imagens e uso de font-display: swap. O resultado sao sites que consistentemente alcancam notas 95+ no PageSpeed Insights, mesmo em conexoes 3G.
Na CloudBird, cada site e auditado nos Core Web Vitals antes do deploy. Oferecemos garantia de performance minima de 90+ no PageSpeed Insights para todos os nossos planos.