Core Web Vitals: o que são e como melhorar cada métrica

Core Web Vitals são um conjunto de métricas criadas para medir experiência real de carregamento e uso de uma página, indo além de números técnicos abstratos e tentando capturar o que o usuário efetivamente sente ao navegar. Elas viraram parte do critério de ranqueamento de busca e, mais importante ainda, um indicador direto de conversão: sites mais rápidos e estáveis retêm mais visitantes.

LCP: a velocidade percebida de carregamento#

Largest Contentful Paint mede o tempo até o maior elemento visível da tela — geralmente uma imagem de destaque ou um bloco de texto principal — terminar de renderizar. É a métrica mais próxima de responder à pergunta que todo usuário faz sem perceber: 'o conteúdo já carregou?'. Manter esse elemento fora de scripts que atrasam o carregamento, usar preload para recursos críticos e servir imagens em formato otimizado são as alavancas mais diretas para melhorá-lo.

INP: resposta à interação do usuário#

Interaction to Next Paint substituiu métricas antigas de responsividade e mede o tempo entre um clique, toque ou tecla pressionada e o momento em que a tela reflete visualmente essa ação. JavaScript pesado bloqueando a thread principal é o vilão mais comum aqui. Dividir tarefas longas em pedaços menores, adiar scripts não essenciais e reduzir o volume total de JavaScript executado no carregamento inicial são os caminhos mais eficazes de melhoria.

CLS: estabilidade visual da página#

Cumulative Layout Shift mede o quanto elementos da página se movem inesperadamente enquanto ela carrega — aquele clique que erra o alvo porque um banner apareceu de repente empurrando tudo para baixo. Reservar espaço explícito para imagens e vídeos antes de carregarem, evitar inserir conteúdo dinâmico acima do que já está visível, e usar font-display swap para fontes personalizadas eliminam a maior parte dos deslocamentos inesperados.

Como medir de forma que os números signifiquem algo#

Medir em ambiente de laboratório, num computador potente e conexão rápida, mostra um cenário otimista que raramente reflete a experiência real. Dados de campo, coletados de usuários reais navegando em condições reais de rede e dispositivo, no percentil 75, são o padrão usado para avaliar se um site realmente passa nos Core Web Vitals. Um site pode parecer rápido no laboratório e falhar completamente nesse critério com usuários reais.

Ferramentas de medição: laboratório versus campo#

Ferramentas como Lighthouse rodam em ambiente de laboratório e são úteis para depuração rápida durante o desenvolvimento, enquanto o Chrome UX Report, conhecido como CrUX, agrega dados reais de campo coletados de usuários de verdade que navegaram pelo site. PageSpeed Insights combina as duas visões em um único relatório, mostrando tanto o diagnóstico de laboratório quanto, quando disponível, o histórico real de campo para a mesma URL.

Mobile primeiro: onde as métricas mais doem#

As três métricas costumam se comportar de forma bem diferente entre mobile e desktop, já que processadores mais fracos e conexões mais instáveis tornam o mobile consistentemente mais sensível a JavaScript pesado e a imagens mal otimizadas. Como o critério de avaliação usado pelos buscadores prioriza a experiência mobile, otimizar pensando primeiro nesse cenário mais restrito tende a beneficiar automaticamente a experiência desktop também.

Frameworks modernos e o custo de JavaScript#

Frameworks modernos de frontend facilitam muita coisa, mas também podem introduzir JavaScript desnecessário se usados sem cuidado, prejudicando diretamente o INP. Técnicas como renderização no servidor, hidratação parcial e carregamento tardio de componentes que não aparecem imediatamente na tela ajudam a manter a interatividade rápida mesmo em aplicações com bastante lógica de interface.

O padrão continua evoluindo#

Vale lembrar que essas três métricas continuam evoluindo junto com o próprio padrão da web: o conjunto de Core Web Vitals já passou por revisões desde seu lançamento, substituindo métricas antigas por versões que refletem melhor a experiência real percebida. Acompanhar essas mudanças evita otimizar para um critério que já deixou de ser o oficial usado pelos buscadores.

Elementos que costumam confundir na medição do LCP#

Nem sempre o elemento identificado como o maior conteúdo visível é o que intuitivamente parece ser o mais importante da página: um vídeo de fundo decorativo, um carrossel de banners ou até um elemento de propaganda podem ser eleitos como o elemento de LCP em vez do título principal ou da imagem de destaque do conteúdo, distorcendo a métrica em relação à real experiência de leitura pretendida pelo time editorial. Revisar periodicamente qual elemento está sendo identificado como LCP em páginas-chave do site, usando as ferramentas de diagnóstico disponíveis, evita otimizar o elemento errado enquanto o conteúdo que realmente importa para o usuário continua carregando devagar.

Time to First Byte e a base de tudo#

Antes de qualquer otimização de frontend fazer efeito, o servidor precisa responder rapidamente à requisição inicial — métrica conhecida como Time to First Byte. Um backend lento, uma consulta de banco de dados não otimizada na rota principal, ou a ausência de cache no lado do servidor colocam um teto baixo em qualquer tentativa de melhorar o LCP, já que nenhuma otimização de imagem ou de JavaScript compensa vários segundos de espera antes mesmo do primeiro byte de HTML chegar ao navegador do usuário. Investir em cache de resposta, CDN para conteúdo estático e otimização de consultas críticas do backend costuma trazer o ganho fundacional sobre o qual todas as outras otimizações de frontend se apoiam.

O papel do hospedeiro e da CDN na performance#

A escolha de onde e como o site é hospedado influencia diretamente as três métricas, especialmente o LCP e o TTFB que o sustenta. Servidores geograficamente distantes do usuário, sem uma rede de distribuição de conteúdo posicionando cópias do site perto de cada região de acesso, adicionam latência que nenhuma otimização de código consegue compensar totalmente. Investir em uma CDN bem configurada, com cache adequado para ativos estáticos e, quando possível, para páginas HTML inteiras, costuma trazer ganho de performance mais consistente entre diferentes regiões do que otimizações pontuais de código isoladas.

Perguntas frequentes sobre Core Web Vitals#

Um site precisa passar nas três métricas para não ser penalizado na busca? O critério oficial considera a experiência de página como um entre vários fatores de ranqueamento, então não passar não significa desaparecer dos resultados, mas sites concorrentes com melhor experiência tendem a levar vantagem em situações de empate técnico de relevância de conteúdo. Rodar um teste isolado no Lighthouse é suficiente para saber se o site está bem? Não — o Lighthouse mostra um retrato de laboratório em condições controladas; a avaliação que realmente importa para SEO usa dados reais de campo, coletados de visitantes de verdade ao longo de várias semanas.

Monitoramento contínuo evita regressão silenciosa#

Equipes que tratam essas métricas como parte do processo de revisão de código, com verificação automática antes de qualquer mudança ir para produção, evitam o cenário mais comum de regressão: uma alteração aparentemente inofensiva em uma dependência ou em um componente visual que silenciosamente piora a experiência de milhares de usuários. Configurar um orçamento de performance no pipeline de integração contínua, que trava o merge quando uma métrica ultrapassa o limite definido, transforma a boa intenção em uma barreira técnica real, em vez de depender só da atenção manual de cada desenvolvedor em cada revisão de código.

Fontes web e o impacto no LCP e no CLS#

Fontes personalizadas carregadas de forma externa podem atrasar tanto a renderização do texto principal, afetando o LCP quando esse texto é o maior elemento da tela, quanto causar um deslocamento visual perceptível quando o texto é primeiro exibido com uma fonte substituta e depois trocado pela fonte final, afetando o CLS. Pré-carregar a fonte crítica com prioridade alta, usar métricas de fonte ajustadas para minimizar a diferença de tamanho entre a fonte substituta e a final, e limitar o número de variações de peso e estilo carregadas simultaneamente são táticas concretas que reduzem esse impacto duplo nas métricas.

Imagens: o maior vilão silencioso do LCP#

Imagens mal otimizadas continuam sendo, na prática, a causa mais comum de LCP ruim em sites de conteúdo. Servir a imagem no tamanho exato necessário para cada breakpoint de tela, em vez de uma única imagem grande redimensionada pelo navegador, usar formatos modernos com melhor taxa de compressão, e aplicar carregamento prioritário — nunca lazy — especificamente na imagem que compõe o maior elemento visível da dobra inicial são ajustes que costumam trazer o ganho mais significativo e mais barato de implementar entre todas as otimizações possíveis de performance web.

Terceiros: scripts de analytics, chat e anúncios#

Scripts de terceiros, como ferramentas de analytics, widgets de chat ao vivo e tags de anúncios, são uma causa recorrente e subestimada de degradação das três métricas, já que fogem do controle direto do time de desenvolvimento do site e costumam ser adicionados sem uma avaliação rigorosa de impacto de performance antes da integração. Carregar esses scripts de forma assíncrona, adiada para depois do conteúdo principal, ou até removê-los quando o valor de negócio não justifica o custo de performance, costuma trazer ganhos de Core Web Vitals maiores do que otimizações no próprio código da aplicação.

Impacto direto em conversão e receita#

Além do efeito indireto no ranqueamento de busca, existe uma correlação bem documentada entre performance de carregamento e taxa de conversão medida diretamente por empresas de e-commerce e mídia: cada segundo adicional de atraso no carregamento tende a reduzir a taxa de conversão de forma mensurável, e páginas com CLS alto, onde botões se movem inesperadamente, aumentam a taxa de cliques acidentais e o abandono por frustração do usuário. Justificar investimento em performance como uma questão puramente técnica costuma ter menos força perante a liderança de negócio do que apresentar esses números de impacto direto em receita, medidos no próprio funil de conversão da empresa.

As três métricas juntas formam um contrato mínimo de qualidade: um site só passa de verdade quando LCP, INP e CLS estão dentro da faixa recomendada simultaneamente, não isoladamente. Tratá-las como budget monitorado continuamente, e não como uma auditoria pontual, é o que evita que uma regressão silenciosa passe despercebida por meses.