Core Web Vitals: guia prático para sites rápidos e estáveis

As três métricas olham para momentos diferentes da visita. O LCP (Largest Contentful Paint) marca quando aparece o maior bloco de imagem, texto ou vídeo visível na tela. O INP (Interaction to Next Paint) observa os cliques, os toques e as teclas da visita inteira e informa a interação mais lenta, do gesto até o próximo quadro desenhado. O CLS (Cumulative Layout Shift) mede a maior rajada de deslocamentos inesperados do layout.

O número que vale é o do 75º percentil, separado entre celular e computador: a página fica na faixa boa quando pelo menos três de cada quatro visitas ficam abaixo do limite. O INP entrou no lugar do FID (First Input Delay) como métrica de resposta em 12 de março de 2024.

A documentação do Google Search afirma que os Core Web Vitals são usados pelos sistemas de classificação da busca. A mesma página põe o peso no lugar: o Google procura mostrar o conteúdo mais relevante mesmo quando a experiência da página é fraca, e bons números não garantem as primeiras posições.

Por isso, tratamos as métricas como medida da visita, não como truque de ranking. Uma página que demora a mostrar o conteúdo, que não responde ao toque ou que pula de lugar atrapalha a leitura e o contato antes de qualquer efeito na busca.

Há dois tipos de dado, e eles respondem perguntas diferentes. Dados de campo vêm de visitas reais, com os aparelhos e as redes de quem usa o site. Dados de laboratório vêm de um teste num ambiente controlado: servem para achar a causa e repetir a medida depois da correção. O campo diz se a correção chegou a quem visita.

• PageSpeed Insights

  Mostra os dois tipos lado a lado: os dados de campo do Chrome User Experience Report (CrUX), com os últimos 28 dias de visitas, e um teste de laboratório feito com o Lighthouse.

• Relatório Core Web Vitals do Search Console

  Agrupa as URLs parecidas do site nas faixas Bom, Melhorias necessárias e Ruim, separando celular e computador, com os dados de campo do CrUX. É o melhor lugar para ver o site inteiro de uma vez.

• Lighthouse

  Roda no Chrome e no PageSpeed Insights, em laboratório. Como o teste não tem uma pessoa interagindo com a página, o INP é aproximado pelo Total Blocking Time (TBT).

• A biblioteca web-vitals

  Para medir no próprio site, a biblioteca JavaScript web-vitals lê as métricas nas visitas reais e permite enviar os valores à ferramenta de análise que o site já usa.

O primeiro passo é saber qual é o elemento do LCP: pode ser uma imagem, o pôster de um vídeo, uma imagem de fundo ou um bloco de texto. Depois, o tempo se divide em quatro partes: a chegada do primeiro byte do HTML, a espera até o navegador começar a baixar o recurso, o download e a espera até o elemento ser desenhado. A correção depende da parte que pesa mais.

• Servidor que responde rápido

  O tempo até o primeiro byte cai com CDN, cache e sem redirecionamentos em cadeia. Páginas geradas como HTML estático no build já estão prontas quando o pedido chega.

• Imagem principal encontrável no HTML

  Se o endereço da imagem só aparece depois que um script roda, o download começa tarde. O recurso do LCP deve estar no HTML que chega do servidor, numa tag <img> ou num preload.

• Prioridade alta, nunca adiada

  A imagem do LCP não deve usar loading="lazy", e fetchpriority="high" pede ao navegador que a busque antes das outras.

• Arquivo do tamanho da tela

  Com srcset e sizes, o navegador escolhe o arquivo adequado à largura da tela, sem baixar no celular a foto feita para o computador. WebP e AVIF comprimem melhor que JPEG e PNG.

• Nada bloqueando o desenho

  Mesmo com a imagem baixada, o elemento espera se houver folhas de estilo ou scripts síncronos ainda carregando no <head>, se ele depender de JavaScript para entrar na página ou se a thread principal estiver ocupada com tarefas longas.

Cada interação tem três fases: a espera até o navegador começar a tratar o evento, o tempo do código que responde a ele e o tempo até o próximo quadro aparecer. As três dependem da thread principal, que faz uma tarefa de cada vez: quando ela está ocupada, o clique espera.

• Quebrar tarefas longas

  Uma tarefa que ocupa a thread principal por mais de 50 milissegundos é uma tarefa longa. A saída é dividir o trabalho e devolver a vez ao navegador entre as partes, com scheduler.yield() onde houver suporte.

• Mostrar a resposta primeiro

  No código do evento, o web.dev recomenda rodar só o que muda a tela no próximo quadro e deixar o resto para uma tarefa seguinte.

• Menos script durante o carregamento

  Enquanto a página carrega, a avaliação dos scripts cria tarefas longas, e um toque nesse momento espera por elas. Por isso, nos sites que fazemos, o JavaScript fica só nas partes que interagem, como no site da ABRAEL.

• DOM enxuto

  Um DOM grande deixa cada atualização da tela mais cara e atrasa o próximo quadro. Ler medidas do layout logo depois de mudá-lo também força o navegador a recalcular tudo na hora, o layout thrashing.

Rolar a página e passar o mouse não contam para o INP; cliques, toques e teclas, sim. Menus, abas, filtros e formulários são os primeiros lugares a testar.

• Medidas em imagens e vídeos

  Com width e height, ou aspect-ratio no CSS, o navegador reserva o espaço antes de o arquivo chegar, e o texto não desce quando a imagem aparece.

• Lugar guardado para o que chega depois

  Anúncios, vídeos incorporados e blocos que um script insere empurram o conteúdo se não tiverem espaço reservado. O que chega tarde deve entrar mais abaixo na página, longe do que a pessoa já está lendo.

• Animar com transform

  Mudar top e left desloca o layout; animações com transform movem, ampliam ou giram o elemento sem mexer no resto da página.

• Fontes que não mudam o tamanho do texto

  Quando a fonte da página chega e substitui a de reserva, as linhas podem mudar de comprimento. O web.dev descreve como pré-carregar a fonte e ajustar a de reserva para reduzir esse salto.

Deslocamentos que acontecem até 500 milissegundos depois de um clique, um toque ou uma tecla não contam, porque a pessoa espera que a página mude. Uma sanfona que abre ao toque não é o problema; um aviso que empurra o texto sozinho, sim.

Páginas que podem usar o cache de voltar e avançar (bfcache) reaparecem prontas, sem os deslocamentos do carregamento, quando a pessoa usa o botão de voltar.

Uma correção termina quando o dado de campo confirma. No relatório do Search Console, depois de corrigir um grupo de URLs, o botão “Iniciar rastreamento” acompanha a correção por 28 dias, o mesmo período dos dados de campo do CrUX.

Entre uma confirmação e outra, um teste de laboratório antes de cada publicação mostra se uma imagem nova, um script de terceiros ou uma animação pesaram na página antes de chegarem a quem visita.