Core Web Vitals: LCP, INP e CLS, com 25 correções

Core Web Vitals: LCP, INP e CLS explicados

Core Web Vitals explicados: LCP, INP, CLS e 25 correções com código | We.Inc

O que LCP, INP e CLS medem, os limites bons e ruins, dados de campo e de laboratório, um medidor ao vivo para esta página e 25 receitas de correção com código agrupadas por causa, além de notas por plataforma.

Core Web Vitals são três medições de visitas reais: Largest Contentful Paint (carregamento, bom com 2.5 segundos ou menos), Interaction to Next Paint (responsividade, bom com 200 milissegundos ou menos) e Cumulative Layout Shift (estabilidade, bom com 0.1 ou menos). Uma página passa quando pelo menos 75% das visitas atingem os três.

Pontuações boas

O medidor abaixo mede esta página no seu próprio navegador enquanto você a usa. Depois, encontre a métrica em que você está reprovando e siga as receitas para ela; cada uma diz qual causa corrige e traz o código.

Perguntas frequentes

O que substituiu o First Input Delay?

O Interaction to Next Paint substituiu o First Input Delay como Core Web Vital em março de 2024. O INP considera todas as interações da página, não só a primeira, e inclui o tempo para pintar o resultado.

Por que minha nota no Lighthouse é boa, mas os Core Web Vitals reprovam?

O Lighthouse é um teste em um dispositivo simulado. Os Core Web Vitals usam visitantes reais ao longo de 28 dias, em celulares e redes mais lentos, e incluem o INP, que o Lighthouse não consegue medir.

Os Core Web Vitals afetam o ranking no Google?

Eles fazem parte dos sinais de experiência na página do Google. O Google descreve relevância e qualidade do conteúdo como muito mais importantes, então bons vitals ajudam mais quando as páginas são parecidas em todo o resto.

Quanto tempo até as correções aparecerem?

Os dados de campo cobrem os 28 dias anteriores, então as melhorias aparecem aos poucos ao longo de cerca de quatro semanas depois da publicação.

Como isso difere de uma nota de velocidade

As três métricas

Limites (avaliados no percentil 75 das visitas reais)

Dados de campo e dados de laboratório

Dados de campo e dados de laboratório

Corrigindo o LCP (receitas 1 a 9)

1. Busque a imagem principal primeiro

fetchpriority="high" diz ao navegador que esta imagem é a mais importante. Nunca use lazy-load na imagem do LCP.

2. Faça preload de uma imagem de LCP definida no CSS

Imagens de fundo são descobertas tarde, depois que o CSS carrega. Um preload no head inicia o download na hora.

3. Entregue o tamanho certo

srcset e sizes deixam um celular baixar um arquivo pequeno em vez do arquivo de desktop.

4. Use um formato de imagem moderno

AVIF e WebP costumam ser bem menores que JPEG com a mesma qualidade. picture permite que navegadores antigos usem uma alternativa.

5. Não esconda o texto enquanto as fontes carregam

font-display: swap mostra o texto com a fonte alternativa na hora, então um título que é o elemento de LCP não fica esperando o download da fonte.

6. Conecte cedo à CDN de imagens

preconnect faz o handshake de DNS, TCP e TLS antecipadamente para uma origem de terceiros que você vai precisar.

7. Adie scripts que não são necessários para mostrar a página

Scripts no head sem defer ou async bloqueiam a renderização. defer mantém a ordem, mas espera o HTML ser analisado.

8. Envie HTML de verdade, não uma casca vazia

Se o elemento de LCP é criado por JavaScript, nada pode ser pintado até o bundle baixar e rodar. Renderização no servidor ou pré-renderização o coloca na primeira resposta. Veja nosso guia de SEO para single page apps para conhecer as opções.

9. Faça cache do HTML na borda

Uma resposta lenta do servidor atrasa tudo. Faça cache de páginas estáticas em uma CDN e defina um Cache-Control sensato.

Corrigindo o INP (receitas 10 a 17)

10. Divida tarefas longas

Uma tarefa acima de 50 ms bloqueia a entrada. Devolva o controle à thread principal entre os blocos para que um clique possa ser tratado no meio. scheduler.yield é mais novo; a alternativa com setTimeout funciona em todo lugar.

11. Pinte o feedback primeiro, trabalhe depois

Atualize o botão imediatamente e só faça o trabalho pesado depois que o navegador tiver a chance de pintar.

12. Use debounce no trabalho ligado à digitação

Filtrar uma lista longa a cada tecla faz a digitação travar. Espere uma pausa curta.

13. Marque atualizações lentas do React como transições

startTransition deixa o React manter o campo responsivo e renderizar o resultado pesado quando puder.

14. Atrase scripts de terceiros

Widgets de conversa e gerenciadores de tags muitas vezes rodam código pesado no carregamento. Carregue-os depois que a página ficar ociosa ou na primeira interação.

15. Mantenha o DOM pequeno

Páginas enormes deixam toda atualização de estilo e layout mais lenta. content-visibility pula a renderização de seções fora da tela até elas chegarem perto.

16. Não leia o layout dentro de um loop de escrita

Ler offsetHeight depois de cada mudança de estilo força um layout toda vez. Leia tudo primeiro e depois escreva.

17. Mova cálculos pesados para um Web Worker

Analisar um arquivo grande ou ordenar milhares de linhas pode rodar em um worker sem bloquear cliques.

Corrigindo o CLS (receitas 18 a 25)

18. Dê um tamanho a imagens e vídeos

width e height permitem que o navegador reserve o espaço antes de o arquivo chegar. O CSS ainda pode deixá-los responsivos.

19. Reserve espaço para embeds

Mapas, vídeos e iframes costumam carregar tarde. aspect-ratio mantém a caixa deles aberta.

20. Reserve espaço para banners e anúncios

Conteúdo inserido acima do que as pessoas estão lendo empurra o texto para baixo. Dê ao espaço uma altura mínima com antecedência.

21. Iguale o tamanho da fonte alternativa

Quando a fonte web entra no lugar, o texto pode quebrar linhas de outro jeito. size-adjust em uma fonte alternativa local deixa as duas mais próximas em largura.

22. Anime com transform, não com top ou height

Mover coisas com transform não desloca outros elementos, então não conta como mudança de layout.

23. Sobreponha barras de cookies em vez de empurrar o conteúdo

Uma barra fixa na parte de baixo da tela não move a página; uma inserida no topo move.

24. Use skeletons do mesmo tamanho do conteúdo

Um placeholder de carregamento deve ocupar o mesmo espaço do que vai substituí-lo.

25. Mantenha o cache de voltar/avançar funcionando

Páginas restauradas do cache de voltar/avançar aparecem na hora, sem novas mudanças de layout. Um handler de unload impede isso; use pagehide no lugar.

Notas por plataforma

Notas por plataforma

Imagens são o culpado habitual do LCP; reduza-as com o

conversor para WebP

Medidor ao vivo desta página

Mede LCP, CLS e INP desta página no seu navegador, quando houver suporte.

Bom

Precisa melhorar

Ruim

Sem suporte neste navegador

INP (o mais lento até agora)

Aguardando a maior pintura

Clique ou digite em qualquer lugar para medir

Comece grátis · Sem cartão de crédito

Relacionados: Guias

Produto

Para quem é

Recursos

Recursos

Empresa

Mapa do site