Core Web Vitals explicados: LCP, INP e CLS em linguagem simples

Os Core Web Vitals não são um teste de personalidade para o seu website

Os Core Web Vitals são muitas vezes tratados como um boletim de pontuação misterioso. Uma página recebe um número vermelho, alguém publica uma captura de ecrã no Slack, e a equipa começa a discutir sobre frameworks JavaScript.

Isso não é especialmente útil.

A melhor forma de pensar nos Core Web Vitals é mais simples: são três medições de se uma página parece utilizável para uma pessoa real num dispositivo real. Não capturam todos os aspetos de desempenho, acessibilidade ou qualidade. Mas detetam três fontes comuns de frustração:

• O conteúdo principal demora demasiado a aparecer.
• A página reage lentamente quando o utilizador tenta fazer alguma coisa.
• O layout salta enquanto o utilizador está a ler ou a tocar.

Esses são os três Core Web Vitals: LCP, INP e CLS.

A Google usa-os como parte dos seus sinais de experiência da página, mas o ângulo de SEO não é a melhor razão para lhes prestar atenção. A melhor razão é que páginas lentas, instáveis e sem resposta desperdiçam o tempo dos utilizadores. Também tendem a converter pior, a dar mais trabalho ao suporte e a envelhecer mal.

As três métricas numa frase cada

Antes de entrar nos detalhes, eis a versão em linguagem simples:

• LCP, ou Largest Contentful Paint, mede quanto tempo demora o principal conteúdo visível a carregar.
• INP, ou Interaction to Next Paint, mede quão rapidamente a página responde às interações do utilizador ao longo da visita.
• CLS, ou Cumulative Layout Shift, mede quanto a página se move inesperadamente.

Os limiares habituais são:

| Métrica | Bom | Precisa de melhoria | Fraco | |---|---:|---:|---:| | LCP | 2,5s ou menos | 2,5s–4,0s | Mais de 4,0s | | INP | 200ms ou menos | 200ms–500ms | Mais de 500ms | | CLS | 0,1 ou menos | 0,1–0,25 | Mais de 0,25 |

Estes números são normalmente avaliados no 75.º percentil das visitas de utilizadores reais. Isso importa. Não está a tentar produzir uma execução perfeita em laboratório. Está a tentar tornar a experiência boa para a maioria dos utilizadores, incluindo pessoas em telemóveis mais lentos e redes mais instáveis.

Se está a olhar para um relatório automatizado e não sabe por onde começar, ajuda separar o diagnóstico do pânico. Temos um guia separado sobre como ler um relatório Lighthouse sem entrar em pânico, que cobre esse fluxo de trabalho com mais detalhe.

LCP: quando é que a página parece carregada?

Largest Contentful Paint mede o tempo de renderização do maior elemento de conteúdo visível na viewport. Na prática, isso é muitas vezes:

• uma imagem hero,
• um cabeçalho grande,
• uma imagem de artigo em destaque,
• uma imagem de produto,
• um grande bloco de texto.

O LCP não pergunta quando todos os scripts, píxeis de tracking e imagens abaixo da dobra acabaram de carregar. Pergunta: quando é que a coisa principal que o utilizador veio ver se tornou visível?

Isso faz do LCP uma métrica mais humana do que o antigo “tempo de carregamento da página”. Uma página pode tecnicamente acabar de carregar tarde e, ainda assim, parecer rápida se o conteúdo principal aparecer depressa. O inverso também é verdade: uma página pode disparar o evento de carregamento enquanto a área hero ainda está em branco, desfocada ou bloqueada por um atraso de renderização.

Causas comuns de LCP fraco

A maioria dos problemas de LCP fraco vem de alguns sítios previsíveis:

1. Resposta lenta do servidor

Se o documento HTML chega tarde, todo o resto começa tarde.

1. CSS ou JavaScript que bloqueiam a renderização

O browser tem o conteúdo, mas ainda não o consegue pintar.

1. Imagens hero não otimizadas

O maior elemento é demasiado grande, está no formato errado, não tem prioridade ou é carregado com lazy loading por engano.

1. Web fonts que atrasam a renderização do texto

Um cabeçalho grande pode ser o elemento LCP, e o carregamento da fonte pode atrasá-lo ou alterá-lo visualmente.

1. Atrasos de renderização no lado do cliente

Se a página precisa de um bundle JavaScript grande antes de conseguir mostrar conteúdo significativo, o LCP sofre.

Como melhorar o LCP

Comece pelo elemento LCP real. Não otimize recursos aleatórios até saber o que o browser está a medir.

Correções práticas incluem:

• Servir HTML rapidamente: usar cache quando apropriado, reduzir trabalho no backend, evitar redirects lentos.
• Otimizar a imagem LCP: usar as dimensões, compressão e formato corretos.
• Não aplicar lazy loading à imagem hero acima da dobra.
• Usar fetchpriority="high" com cuidado para a imagem principal quando ela é realmente a prioridade.
• Colocar CSS crítico inline apenas quando isso reduz de forma significativa o atraso de renderização.
• Reduzir o JavaScript necessário antes da primeira renderização significativa.
• Usar font-display: swap ou outra estratégia de fontes intencional.

Imagens e fontes são culpados frequentes. Nas imagens, o compromisso não é apenas “ficheiro pequeno é bom”. A escolha do formato, o esforço de codificação e o suporte dos browsers também importam, razão pela qual mantemos uma árvore de decisão prática para quando AVIF bate WebP e quando não bate. Para páginas com muito texto, as web fonts continuam a ser uma das vitórias de desempenho mais fáceis, porque muitos sites enviam mais ficheiros de fontes do que aqueles que usam.

INP: a página responde quando é tocada?

Interaction to Next Paint mede a capacidade de resposta. Mais especificamente, observa o atraso entre uma interação do utilizador e a próxima atualização visual depois de o browser ter processado essa interação.

As interações incluem coisas como:

• clicar num botão,
• tocar num menu,
• selecionar uma checkbox,
• escrever num campo de formulário,
• abrir um acordeão.

O INP substituiu o First Input Delay como Core Web Vital em 2024. Foi uma boa mudança. O First Input Delay olhava apenas para a primeira interação. O INP é mais abrangente: considera interações ao longo de toda a visita à página e reporta uma interação de alta latência como a pontuação de capacidade de resposta da página.

Em linguagem simples: o INP deteta páginas que parecem carregadas, mas se sentem bloqueadas.

Provavelmente já usou uma página assim. Parece pronta. Toca no menu. Nada acontece durante meio segundo. Toca outra vez. Depois acontecem duas coisas ao mesmo tempo. Isso é um problema de INP.

Causas comuns de INP fraco

O INP é normalmente um problema da main thread. O browser quer responder, mas JavaScript, trabalho de renderização ou cálculo de layout estão no caminho.

Causas típicas incluem:

• bundles JavaScript grandes,
• event handlers dispendiosos,
• trabalho de hidratação em aplicações renderizadas no cliente,
• scripts de terceiros a competir pela main thread,
• tarefas longas depois do carregamento da página,
• atualizações complexas do DOM acionadas por pequenas interações,
• layout thrashing, quando o código lê e escreve repetidamente valores de layout.

Tags de marketing, analytics, widgets de chat e banners de consentimento podem todos contribuir. Isto não significa “remover tudo”. Significa que cada script na página tem um custo, e a latência de interação é onde esse custo muitas vezes se torna visível.

Como melhorar o INP

Melhorar o INP tem menos a ver com um atributo mágico e mais com reduzir a contenção na main thread.

Abordagens úteis incluem:

• Dividir tarefas JavaScript longas em blocos mais pequenos.
• Adiar trabalho não essencial até a página estar utilizável.
• Remover JavaScript não usado, em vez de apenas o minificar.
• Manter os event handlers pequenos e previsíveis.
• Evitar renderizar novamente grandes partes da interface por mudanças de estado mínimas.
• Usar CSS para estados visuais simples sempre que possível.
• Auditar scripts de terceiros e carregá-los apenas onde são necessários.

Observe também o design de interação. Um botão que dá feedback visual imediato pode parecer mais responsivo, mesmo que o trabalho seguinte demore mais. Isso não substitui desempenho, mas faz parte de uma boa engenharia de interface. A nossa checklist para botões web acessíveis sobrepõe-se a isto: estados claros, semântica adequada e comportamento previsível ajudam tanto os utilizadores como os browsers.

CLS: a página fica onde o utilizador espera?

Cumulative Layout Shift mede o movimento inesperado de elementos visíveis. Se um utilizador começa a ler um parágrafo e um anúncio, imagem ou banner carrega acima dele, empurrando o texto para baixo, isso contribui para o CLS.

O CLS não é medido em segundos. É uma pontuação baseada em quanto conteúdo se moveu e em que distância se moveu. Quanto mais baixo, melhor.

A palavra-chave é inesperado. Alterações de layout causadas por uma ação do utilizador normalmente não são contadas da mesma forma. Se alguém toca em “mostrar mais” e o conteúdo se expande, isso é esperado. Se um banner de newsletter aparece no topo após três segundos e empurra tudo para baixo, isso não é.

Causas comuns de CLS fraco

As falhas de CLS são muitas vezes banais:

• imagens sem atributos width e height,
• anúncios ou embeds sem espaço reservado,
• banners de cookies inseridos acima do conteúdo,
• web fonts que entram com métricas diferentes,
• barras promocionais carregadas tardiamente,
• conteúdo injetado dinamicamente perto do topo da página.

A correção é normalmente reservar espaço antes de o conteúdo chegar. O browser deve conhecer a forma da página o mais cedo possível.

Como melhorar o CLS

Comece pelos deslocamentos visíveis. Veja uma gravação ou use ferramentas do browser para identificar que elementos se movem.

Depois aplique as correções aborrecidas:

• Adicionar atributos width e height explícitos às imagens.
• Usar CSS aspect-ratio para contentores de media responsivos.
• Reservar espaço fixo ou mínimo para anúncios, embeds e iframes.
• Evitar injetar banners acima de conteúdo existente após o carregamento.
• Escolher fallbacks de fontes com métricas semelhantes às da fonte final.
• Evitar animações que alterem propriedades de layout como top, left, width ou height; preferir transforms.

O CLS é uma das poucas métricas de desempenho em que a disciplina vence a esperteza. Se a página tem caixas estáveis, tende a pontuar bem.

Dados de campo e dados de laboratório são ambos úteis, mas respondem a perguntas diferentes

Uma fonte comum de confusão é que ferramentas diferentes mostram números diferentes. Isso é normal.

Dados de campo vêm de utilizadores reais. Refletem dispositivos, redes, localizações e condições de browser reais. O Chrome User Experience Report da Google é um exemplo de dados de campo.

Dados de laboratório vêm de um ambiente de teste controlado. Lighthouse é o exemplo familiar. É repetível e útil para depuração, mas não é o mesmo que a experiência vivida pelos seus utilizadores.

Use dados de campo para decidir se os utilizadores têm um problema real. Use dados de laboratório para reproduzir e depurar esse problema.

Lembre-se também de que os Core Web Vitals são normalmente avaliados por URL ou grupo de URLs, não como uma propriedade abstrata única da sua marca. A sua página inicial, artigo de blog, página de preços e checkout podem ter gargalos muito diferentes.

Uma ordem de trabalho sensata

Se as três métricas estão fracas, a tentação é começar por todo o lado. Resista.

Uma ordem prática é:

1. Corrigir primeiro o CLS óbvio

Dimensões de imagens em falta e banners instáveis são muitas vezes ganhos rápidos.

1. Melhorar o LCP em templates importantes

Foque-se nas páginas que importam: páginas de produto, landing pages, artigos, fluxos de registo.

1. Investigar o INP com interações reais

Clique naquilo em que os utilizadores realmente clicam. Menus, filtros, formulários e controlos de checkout muitas vezes revelam mais do que o traço de carregamento inicial.

1. Auditar scripts de terceiros

Mantenha os que justificam o seu custo. Remova ou adie os que não justificam.

1. Definir um orçamento de desempenho

Sem um orçamento, as melhorias de desempenho degradam-se. Novos scripts, imagens e componentes de design vão desfazer silenciosamente o trabalho.

O ponto importante: não otimize para um distintivo. Otimize para a jornada do utilizador. Uma melhoria marginal de pontuação numa página com pouco tráfego pode importar menos do que uma interação de checkout ligeiramente imperfeita, mas muito mais rápida.

<!-- tool-cta:start -->

💡 Experimente isto: Como o LCP geralmente é um problema de imagem, reduza o tamanho do seu recurso hero com Image Compressor como uma primeira vitória fácil.

<!-- tool-cta:end -->

O que os Core Web Vitals não lhe dizem

Os Core Web Vitals são úteis, mas incompletos.

Não lhe dizem se o seu conteúdo é bom. Não lhe dizem se a sua navegação faz sentido. Não garantem acessibilidade. Não medem privacidade, segurança, confiança, legibilidade ou se a página responde à pergunta do utilizador.

Também não substituem o julgamento. Uma página pode passar nos Core Web Vitals e ainda assim ser desagradável. Uma aplicação complexa pode falhar um limiar e, ainda assim, estar responsavelmente desenvolvida dentro das suas restrições.

Trate LCP, INP e CLS como alarmes de fumo. Quando disparam, investigue. Quando estão silenciosos, continue a fazer a manutenção do edifício.