Core Web Vitals são três métricas de experiência real de usuários: velocidade de exibição do conteúdo principal (LCP), resposta às interações (INP) e estabilidade visual (CLS). O Google recomenda LCP de até 2,5 segundos, INP de até 200 milissegundos e CLS de até 0,1, medidos no percentil 75 das visitas.
Core Web Vitals são indicadores desenvolvidos pelo Google para avaliar aspectos específicos da experiência de uso de páginas web. Atualmente, o conjunto principal inclui Largest Contentful Paint (LCP), Interaction to Next Paint (INP) e Cumulative Layout Shift (CLS). Eles representam, respectivamente, carregamento percebido, capacidade de resposta e estabilidade visual. Não representam toda a qualidade do site, mas oferecem sinais mensuráveis de problemas comuns.
Pense em uma pessoa que abre uma página de serviços pelo celular. Ela quer ver o conteúdo principal sem demora, tocar no menu sem travamentos e preencher um formulário sem que um banner inesperado empurre os campos para baixo. Cada situação corresponde a uma dimensão diferente do desempenho.
Os limites recomendados pelo Google são LCP de até 2,5 segundos, INP de até 200 milissegundos e CLS de até 0,1. Para considerar a experiência boa, os três indicadores devem atingir suas metas no percentil 75 das visitas analisadas, de forma separada para mobile e desktop. Valores intermediários indicam necessidade de melhoria; os piores limites são LCP acima de 4 segundos, INP acima de 500 milissegundos e CLS acima de 0,25.
Esses números não são uma nota estética nem uma promessa de conversão. Uma página pode atender aos Core Web Vitals e ainda apresentar textos confusos ou um formulário mal projetado. Da mesma forma, uma pontuação alta em teste de laboratório não substitui a observação de visitantes reais.
Largest Contentful Paint mede quando o maior elemento relevante visível na área inicial da página termina de ser renderizado. Em sites corporativos, esse elemento costuma ser a imagem principal ou um grande bloco de texto. Se o servidor demora a responder, a imagem é pesada ou recursos prioritários ficam bloqueados, o LCP tende a piorar.
Exemplo: a home tem uma foto de capa de vários megabytes. O visitante recebe o cabeçalho, mas espera pela imagem principal. Redimensionar o arquivo, usar formatos modernos quando apropriado, evitar lazy loading da imagem crítica e revisar a prioridade de carregamento podem melhorar o resultado. É preciso verificar o elemento que efetivamente está sendo medido antes de aplicar soluções genéricas.
Interaction to Next Paint mede a latência de interações observadas durante a visita, como cliques, toques e ações de teclado, considerando o tempo até uma atualização visual. Um menu que demora a abrir ou um filtro que congela após um clique são exemplos de experiências ruins. A métrica substituiu o FID como Core Web Vital; tutoriais antigos centrados em FID precisam ser atualizados.
Exemplo: um site carrega vários scripts de rastreamento e widgets de terceiros. Ao tocar em “Solicitar orçamento”, o navegador está ocupado executando JavaScript e só responde depois. Reduzir tarefas longas, carregar scripts menos importantes de modo adequado e simplificar componentes interativos pode melhorar o INP. O objetivo não é simplesmente remover funcionalidades, mas eliminar trabalho desnecessário na linha principal.
Cumulative Layout Shift soma deslocamentos inesperados de elementos visíveis durante a experiência. Quando uma imagem carrega sem espaço reservado, o texto abaixo pode ser empurrado. Um banner inserido no topo ou uma fonte que modifica muito o tamanho dos títulos também pode gerar deslocamentos. A métrica não mede velocidade e não tem unidade de tempo.
Exemplo: a pessoa está prestes a clicar em “Enviar”, mas um aviso aparece e desloca o botão. Para reduzir CLS, informe as dimensões das imagens, reserve espaço para embeds e elementos dinâmicos e revise o carregamento das fontes. Não basta esconder o problema visual com animações: é preciso corrigir a origem da mudança.
PageSpeed Insights reúne dados de campo, quando disponíveis, e medições de laboratório com Lighthouse. Dados de campo refletem o uso real agregado, enquanto o laboratório simula condições para diagnosticar oportunidades. Eles podem divergir por diferenças de dispositivos, rede, período e comportamento. O relatório de Core Web Vitals do Search Console ajuda a identificar grupos de URLs afetados.
Ao analisar, compare mobile com mobile e desktop com desktop. Uma página de produto com vídeos e widgets pode ter perfil diferente de uma página textual. Priorize modelos de página que concentram tráfego e conversões, como home, páginas de serviço e landing pages. Depois de corrigir, acompanhe a evolução dos dados de campo, que dependem de novas visitas e não mudam instantaneamente.
O Google utiliza sinais ligados à experiência da página em seus sistemas de classificação, mas não há relação direta garantida entre melhorar uma métrica e subir posições. Conteúdo útil, relevância e adequação à pesquisa continuam determinantes. O foco empresarial deve ser melhorar a experiência e remover obstáculos de navegação, não perseguir um número isolado.
Imagine duas páginas que respondem igualmente bem a uma necessidade. Uma abre rapidamente, responde ao toque e não movimenta elementos; a outra interrompe o usuário repetidamente. A primeira oferece experiência melhor, independentemente de uma mudança mensurável no ranking. Testar taxas de conclusão de formulários e qualidade dos contatos pode mostrar valor que uma ferramenta de desempenho não captura.
| Métrica | Limite bom | O que observar |
|---|---|---|
| LCP | Até 2,5 segundos | Conteúdo principal |
| INP | Até 200 milissegundos | Resposta ao clique |
| CLS | Até 0,1 | Mudança de layout |
Descubra oportunidades e erros que estão travando seu posicionamento.
Faça uma análise agora
Identifique qual métrica falha em qual modelo de página; corrija a causa dominante e meça novamente.
Na avaliação dos Core Web Vitals ligada à experiência na página, o Google Search usa dados de campo do Chrome User Experience Report (CrUX), provenientes de usuários reais do Chrome. Testes de laboratório, como os do Lighthouse no PageSpeed Insights, servem para diagnosticar problemas e verificar correções em condições controladas. Eles não substituem o conjunto de dados de campo que alimenta essa avaliação na Busca.
Os dados de campo vêm do CrUX e só aparecem quando a URL é publicamente descoberta (rastreável e indexável) e há volume suficiente de visitas reais e anonimizadas. Se a página ainda não tem amostras suficientes, o PageSpeed Insights pode exibir o dado agregado da origem, que reúne as visitas de todas as páginas do site. Se a própria origem também não tiver amostras suficientes, a ferramenta não apresenta dados de campo.
Os dados de campo do PageSpeed Insights e do relatório de Core Web Vitals no Search Console refletem uma janela móvel dos 28 dias anteriores e são atualizados diariamente. Uma correção só entra nesse conjunto à medida que novas visitas reais ocorrem. Por isso, o efeito não aparece no mesmo dia e só se reflete por inteiro quando o período completo da janela já inclui as visitas posteriores à correção.
Desenvolvimento Web 
Tráfego Orgânico 
revisado
Calcular valor agora
