LCP, INP, CLS e TTFB: o que cada métrica realmente mede

Entenda o impacto do carregamento síncrono de scripts no bloqueio de renderização e aprenda a aplicar atributos defer e async com segurança.

GESTÃO DE SCRIPTS

10/10/20267 min read

Cada métrica observa um aspecto diferente da experiência. LCP ajuda a entender quando o conteúdo principal aparece; INP avalia a rapidez da resposta visual às interações; CLS mede a instabilidade visual; e TTFB mostra quanto tempo passa até o início da resposta. Nenhuma delas, isoladamente, explica toda a experiência ou identifica automaticamente a causa de um problema.

Essa distinção é importante no WordPress. Um TTFB alto pode apontar para uma questão de conexão, cache ou processamento no servidor, mas não prova que esse seja o motivo de um LCP ruim. Da mesma forma, uma página pode carregar rapidamente e ainda responder mal a cliques ou mover botões enquanto o usuário lê.

O que cada métrica mede

LCP: quando o conteúdo principal aparece

O Largest Contentful Paint registra o momento em que o maior elemento de imagem, texto ou vídeo visível na janela de visualização é renderizado, contado a partir do início da navegação. A documentação atual do web.dev sobre LCP explica que o elemento pode mudar durante o carregamento: um título pode ser o maior candidato inicialmente, mas uma imagem de destaque pode substituí-lo quando terminar de carregar.

Por isso, LCP não é sinônimo de “página totalmente carregada”. Ele depende do elemento identificado, do tamanho da janela, do conteúdo exibido, do carregamento de fontes e imagens e das condições do dispositivo e da rede. O diagnóstico deve verificar qual foi o elemento LCP, e não apenas o número final.

INP: resposta às interações

O Interaction to Next Paint avalia a capacidade de resposta de uma página observando interações de clique, toque e teclado ao longo da visita. Sua latência vai do início da interação até o próximo quadro que o navegador consegue apresentar. Em geral, o valor final representa a interação mais lenta, com tratamento de valores extremos conforme a quantidade de interações. A definição oficial de INP detalha que a latência inclui atraso de entrada, processamento dos callbacks e atraso até a apresentação.

INP não mede todos os efeitos posteriores de uma ação, como uma requisição de rede que termina muito depois. Ele mede principalmente o tempo até o próximo feedback visual. Também não é uma medição fixa apenas do carregamento inicial: uma página com menu, busca, filtros ou carrinho pode ter INP diferente conforme as interações que os usuários realmente fazem.

Desde março de 2024, INP é o Core Web Vital de responsividade e substituiu o FID. A comunicação de lançamento do INP como Core Web Vital confirma essa mudança; relatórios antigos que ainda mencionem FID precisam ser interpretados nesse contexto.

CLS: estabilidade visual

O Cumulative Layout Shift mede a maior soma de mudanças inesperadas de layout que ocorre em uma janela de sessão durante o ciclo de vida da página. Uma janela de sessão reúne deslocamentos separados por menos de um segundo e tem duração máxima de cinco segundos. O valor final é a janela com a maior pontuação acumulada, não simplesmente uma soma ilimitada de tudo o que aconteceu.

A documentação oficial de CLS define deslocamento como a mudança de posição de um elemento visível entre quadros. Imagens ou vídeos sem dimensões reservadas, fontes que alteram a geometria do texto, anúncios e widgets de terceiros que redimensionam o espaço são causas comuns. Mudanças próximas de uma interação do usuário podem ser excluídas quando são consideradas esperadas, portanto o contexto importa.

TTFB: início da resposta

O Time to First Byte mede o tempo entre o início da navegação e o começo da chegada do primeiro byte da resposta. A documentação de TTFB do web.dev decompõe o intervalo em redirecionamentos, inicialização de service worker quando aplicável, DNS, conexão e TLS, além do tempo de espera pelo servidor até o primeiro byte.

TTFB, portanto, não é o tempo total de carregamento e não diz quando o conteúdo principal ficou visível. Uma resposta pode começar cedo, mas ainda depender de CSS, JavaScript, fontes e imagens antes do LCP. Além disso, cache, CDN, distância até o servidor, conexão reutilizada e uso de 103 Early Hints podem alterar a interpretação. O web.dev usa 0,8 segundo como orientação aproximada, não como garantia universal nem como Core Web Vital.

Tabela de leitura e limites

Métrica

O que mede

O que pode influenciá-la

Onde observar

O que não se pode concluir sozinha

LCP

Renderização do maior elemento de conteúdo visível

Imagem hero, fontes, CSS, JavaScript, servidor, rede, viewport e cache

PageSpeed Insights, Lighthouse, CrUX, RUM e DevTools

Que toda a página terminou ou que o servidor é a causa; é preciso ver o elemento LCP e as fases do carregamento

INP

Latência da interação até o próximo feedback visual

Tarefas longas de JavaScript, event handlers, CPU, scripts de terceiros e interação escolhida

PageSpeed Insights/CrUX, Search Console, RUM, DevTools Performance

Que todos os cliques têm a mesma resposta ou que uma requisição posterior terminou; o resultado depende das interações observadas

CLS

Maior janela de mudanças inesperadas de layout

Imagens sem dimensões, fontes, anúncios, embeds, conteúdo inserido e lazy loading

PageSpeed Insights/CrUX, Lighthouse, DevTools Layout Shift e RUM

Que qualquer mudança visual é ruim ou que o problema ocorreu apenas no carregamento inicial; o usuário pode deslocar a página e revelar outros casos

TTFB

Tempo até começar a chegar a resposta

DNS, TLS, rede, CDN, cache, fila e processamento do servidor

DevTools Network, WebPageTest, Navigation Timing, RUM e PageSpeed Insights

Que o conteúdo está visível rapidamente ou que reduzir TTFB produzirá a mesma melhora em LCP/INP/CLS

Campo e laboratório não respondem à mesma pergunta

Dados de campo são coletados de experiências de usuários reais. O CrUX, por exemplo, é um conjunto agregado de navegadores Chrome elegíveis, com variações de dispositivo, rede e localização. O relatório CrUX não cobre necessariamente todo site ou toda URL. O Search Console também agrupa URLs semelhantes e exibe dados agregados, não uma fotografia completa de cada visita.

Dados de laboratório são obtidos em uma execução controlada, normalmente com Lighthouse e configurações predefinidas de dispositivo, CPU, rede e localização. Eles são úteis para reproduzir um problema, comparar uma alteração e investigar a cascata de recursos. Porém, não representam automaticamente o conjunto de usuários reais.

O PageSpeed Insights combina CrUX e Lighthouse: a área de experiência real apresenta dados de campo, enquanto a área de diagnóstico usa laboratório. Os números podem divergir porque usuários têm aparelhos e redes diferentes, podem rolar a página, interagir com componentes, chegar com cache quente ou receber conteúdo personalizado. Um teste de laboratório também pode não encontrar um deslocamento que só aparece depois do scroll.

Quando os dois tipos de dado existem, o campo é a referência principal para saber o que a base real está vivenciando. O laboratório ajuda a formular e testar hipóteses. Nenhum dos dois, sozinho, substitui a inspeção do elemento, da interação ou da requisição envolvida.

Critérios de avaliação, sem promessas

Para Core Web Vitals, as referências oficiais usam o percentil 75, segmentado por dispositivo: LCP de até 2,5 s, INP de até 200 ms e CLS de até 0,1 são classificados como “bom”. As faixas “precisa melhorar” e “ruim” são, respectivamente, intermediárias e acima de 4 s para LCP, 500 ms para INP e 0,25 para CLS. Consulte a documentação do Google Search sobre Core Web Vitals e a metodologia dos limiares do web.dev.

Esses números são critérios de avaliação agregada, não uma promessa de que cada visita será rápida. TTFB aparece como métrica diagnóstica, não como Core Web Vital. Uma classificação “boa” também não identifica a causa nem garante uma posição específica nos resultados de busca.

Exemplo de leitura conjunta

Imagine uma página de artigo com TTFB de 1,2 s no campo, LCP de 3,8 s, INP de 120 ms e CLS de 0,02. A leitura razoável é: há um sinal de latência antes da resposta, e isso pode contribuir para o LCP, mas ainda é preciso verificar cache, localização, tamanho da resposta e o elemento LCP. A boa responsividade não elimina um problema de carregamento.

Agora suponha que o laboratório mostre TTFB de 300 ms e LCP de 2,1 s, enquanto o campo indica valores piores. Isso pode refletir usuários móveis, regiões distantes, cache frio, conteúdo personalizado ou uma distribuição de tráfego diferente. O resultado não prova que o laboratório esteja errado nem que o servidor seja a única causa. A próxima etapa é segmentar os dados e investigar cada hipótese com uma medição reproduzível.

Roteiro para escolher a fonte

1.Quer saber o que usuários reais enfrentam? Comece por CrUX, PageSpeed Insights, Search Console ou RUM próprio; registre período, dispositivo e URL.

2.Quer reproduzir e depurar? Use Lighthouse e DevTools, anotando rede, CPU, localização, cache e viewport.

3.LCP está alto? Identifique o elemento LCP e separe tempo de servidor, carregamento do recurso e renderização.

4.INP está alto? Descubra qual interação foi lenta e examine tarefas longas e callbacks no Performance do DevTools.

5.CLS está alto? Observe os elementos instáveis, inclusive depois do scroll, e reserve dimensões para recursos cujo tamanho seja conhecido.

6.TTFB está alto? Separe conexão, CDN/cache e processamento de origem antes de atribuir a causa a um plugin, tema ou hospedagem.

Meça antes de alterar a produção. Em mudanças de cache, scripts, imagens ou CDN, prefira staging, backup verificado e uma variável por vez. A métrica orienta a investigação; o diagnóstico depende da evidência adicional.