O que Core Web Vitals Realmente Medem e Qual Deles tu Consegues Sentir

Core Web Vitals são três números, e quase tudo escrito sobre eles explica o que medem. A pergunta mais útil é de quem é a experiência que eles medem, porque a resposta está na definição e define o que podes concluir de uma pontuação verde.

Os três, e aquele que desapareceu

Os próprios limiares da Google, em três bandas cada:

• Largest Contentful Paint (LCP): Bom 2500 ms ou menos, Precisa de melhoria 2501 a 4000 ms, Fraco mais de 4000 ms.
• Interaction to Next Paint (INP): Bom 200 ms ou menos, Precisa de melhoria 201 a 500 ms, Fraco mais de 500 ms.
• Cumulative Layout Shift (CLS): Bom 0.1 ou menos, Precisa de melhoria 0.11 a 0.25, Fraco mais de 0.25.

LCP é carregamento: quanto tempo até a coisa maior do ecrã chegar. INP é interatividade: tu toques em algo, e quanto tempo até a página pintar uma resposta. CLS é estabilidade visual, e é o único que não é uma duração; é uma pontuação de quanto o layout se moveu depois de já poderes vê-lo.

First Input Delay já não é um deles. INP substituiu FID e ficou estável em 2024, o que importa principalmente porque qualquer guia escrito antes disso nomeia uma métrica que já não é medida. Se alguém te der um relatório de desempenho com uma coluna FID, está a falar-te de um web diferente.

Qual deles tu consegues sentir

Esta é a parte que vale a pena ter, porque um utilizador nunca relata uma métrica. Relata uma sensação, e a sensação diz-te qual dos três procurar.

“Fiquei sentado a olhar para nada.” Isso é LCP. A página foi alcançada, o servidor respondeu, e a coisa pela qual a pessoa veio não tinha chegado. Nada está partido e nada tem erros.

“Toquei e nada aconteceu, por isso toquei outra vez.” Isso é INP, e o segundo toque é a metade do diagnóstico. Uma página que não pinta uma resposta em alguns centos de milissegundos é pressionada duas vezes, que é como uma ação pretendida se torna duas ações submetidas.

“Saltou e atingi a coisa errada.” Isso é CLS. Uma imagem atrasada ou uma fonte web chegando depois do primeiro render empurra o botão para outro lado entre o olho decidir e o dedo pousar.

Portanto, “o site sente-se lento” é pelo menos três defeitos diferentes, e as palavras que alguém escolhe limitam-no antes de medires qualquer coisa. Isso vale mais do que parece, porque os três não têm nada em comum por baixo: LCP é normalmente bytes e viagens redondas, INP é normalmente JavaScript a ocupar a thread principal, e CLS é normalmente layout para o qual não reservaste espaço.

O percentil 75 é toda a história

Aqui está a frase que muda como lês uma pontuação. A avaliação é feita no percentil 75 dos carregamentos de página, segmentada entre dispositivos móveis e desktop.

Não a média, e não a tua visita. Três quartos dos carregamentos têm de estar dentro ou abaixo do limiar para uma página passar, o que significa um carregamento em quatro é permitido estar pior do que o teu número verde enquanto o número fica verde. Isso não é uma falha na métrica; é o que a métrica diz.

A razão da Google para escolher esse percentil é publicada e vale a pena conhecer, porque explica por que a cauda é deliberada: o percentil 75 garante que a maioria das visitas experimenta o nível alvo de desempenho, enquanto percentis mais elevados dão peso indevido a experiências ruins esporádicas. Com cem visitas, mover a barra para o percentil 75 requer que vinte e cinco delas sejam afetadas antes de a pontuação se mover. Aos 95, precisa apenas de cinco.

Portanto, a decisão de design é ser robusto contra outliers. O custo dessa robustez é que um problema real, repetível, afetando um quinto dos teus visitantes pode ficar abaixo de uma pontuação de aprovação indefinidamente.

Por que a tua própria experiência nunca é a medição

Abre o teu próprio site e quase certamente estás nos três quartos confortáveis, e não por sorte. Estás numa máquina escolhida para trabalho de desenvolvimento, numa ligação pela qual tu pagas, com a cache já quente, as fontes já descarregadas e o service worker já instalado, provavelmente perto de uma localização de edge que te serve em milissegundos de um dígito.

O quarto lento é alguém num telemóvel de gama média num comboio com uma cache fria. Não são uma anomalia. São a parte da medição que não consegues alcançar do teu secretário, que também é a parte para a qual a pontuação é construída para tolerar.

Que é por isso que “está bem para mim” é uma declaração verdadeira e não evidência de nada, e por que uma página pode sentir-se lenta enquanto todas as métricas de servidor dizem que está rápida.

O que uma pontuação de campo não pode fazer

Core Web Vitals conforme a Google as avalia são dados de campo: um agregado sobre uma população de visitas reais. É isso que as torna úteis, e é também o limite.

Um agregado não consegue responder a uma pergunta sobre uma visita. Quando uma pessoa específica diz que o checkout foi inutilizável na terça-feira à tarde, nenhum percentil te diz o que lhes aconteceu, e uma página que passa diz-te apenas que pelo menos três quartos das visitas foram boas. A reclamação é bastante possível de ser do quarto que o limiar foi concebido para absorver.

Portanto, as duas coisas fazem trabalhos diferentes e nenhuma substitui a outra. A pontuação de campo diz-te se a experiência é amplamente aceitável e onde gastar tempo de engenharia. Uma visita capturada diz-te o que aconteceu à pessoa à tua frente. Alcançar a primeira quando alguém pergunta sobre a segunda é como um relatório real fica fechado como não reproduzível.

O que fazer com uma reclamação de lentidão

Três passos, na ordem que menos custa.

Lê as palavras da métrica. À espera, insensível ou em movimento. Isso sozinho escolhe qual dos três investigar e descarta os outros dois.

Obtenha a visita única em vez do agregado. Quando aconteceu, em que dispositivo e conexão, e o que a página estava a fazer na altura. Um percentil não consegue ser reduzido a uma pessoa, mas uma sessão capturada já é uma.

Depois verifica a pontuação de campo, para descobrires se estás a perseguir a cauda ou o meio. Se a página passa e a reclamação é real, estás no quarto concebido, e isso muda a decisão em vez de terminá-la.

Num parágrafo

Core Web Vitals são LCP aos 2500 ms, INP aos 200 ms e CLS em 0.1, avaliados no percentil 75 dos carregamentos e divididos entre móvel e desktop, com FID aposentado em favor de INP. Cada um mapeia para uma reclamação que uma pessoa realmente faz: à espera, a tocar duas vezes, ou a atingir o botão errado. E o percentil significa que um quarto das tuas visitas é permitido estar pior do que a tua pontuação de aprovação, que é por isso uma dashboard verde e um utilizador infeliz são normalmente ambas corretas, e por que resolver isto precisa de uma visita capturada em vez de uma média melhor.