O Limiar em Que Você Confia Não Foi Medido em Você

Tammy Everts puxou um mês de dados reais de usuários de dez grandes varejistas online e plotou o Largest Contentful Paint por sessão contra a taxa de rejeição, um gráfico por site. Nos dez, o LCP ótimo, ou seja, o ponto associado à melhor taxa de rejeição, ficou em algum lugar entre 100 milissegundos e 1 segundo. O limiar do Google para um LCP “bom” é 2,5 segundos. Todos os dez sites tiveram seu melhor engajamento bem antes do número contra o qual estavam sendo avaliados.

Vale demorar nesse resultado, porque 2,5 segundos virou a linha de chegada de fato para muitos times. Bate a meta, ganha o selo verde, segue a vida. O limiar não é desonesto e não foi manipulado. Ele é um agregado de milhões de sites, exatamente o que se propõe a ser. Diz o que é rápido em geral, e não sabe nada sobre os seus usuários, o seu produto ou o seu negócio.

A falha acontece nas duas direções ao mesmo tempo

Dentro de uma amostra de dez, o mesmo número falhou em duas direções opostas.

Everts também mediu onde começa o platô de performance de cada site, o ponto em que ficar mais rápido ou mais lento deixa de fazer qualquer diferença na taxa de rejeição. Nos dez sites, esse platô começou em algum ponto entre 500 milissegundos e 5,6 segundos. Seis deles tinham platô começando depois de 2,5 segundos, então passar na régua do Google deixava engajamento real sobre a mesa. Esses times eram cobrados por uma régua lenta demais para os próprios usuários, e o painel de conformidade dizia que estava tudo certo.

Nos outros quatro, o platô começou antes de 2,5 segundos. Quando esses sites atingiram o limiar recomendado pelo Google, já estavam achatados. Everts é direta: mesmo tecnicamente rápidos o suficiente para o Google, esses quatro já tinham chegado ao fundo em termos de taxa de rejeição. A métrica que estavam otimizando havia parado de prever o desfecho que lhes interessava, e ali também o painel dizia que estava tudo certo.

Um número, dez sites, dois modos de falha opostos, e ambos invisíveis se a única pergunta feita for se você passou. O time do lado lento do platô subinveste e nunca descobre. O time do lado rápido continua comprando milissegundos que já não movem nada, e lança o gasto como trabalho de performance.

A autora se recusa a deixar a própria faixa virar o próximo número emprestado

Everts é enfática antes de começar: isto NÃO é um número novo para você perseguir. Ela repete no fechamento. Trate a pesquisa como metodologia, não como número. Ela também deixa explícito que não está questionando se os Core Web Vitals importam, e afirma que importam sim.

Essa contenção é a parte que de fato viaja. Quem pega 100ms a 1s e prega num épico do Jira reproduziu o erro original um nível abaixo, com uma amostra de dez no lugar de milhões. O que sobrevive à transferência é um teste que se roda nos próprios dados:

Esse limiar tem relação falsificável com um desfecho que nós mesmos medimos?
Onde a nossa curva achata?

Duas perguntas. Nenhuma delas exige fornecedor.

O que a evidência sustenta e o que não sustenta

Os limites importam, e vale enunciá-los antes que alguém me cite a faixa. Dez sites são dez sites. Um mês de dados. Só varejo, então a curva de engajamento de um dashboard B2B não está coberta. A amostra vem da própria base de clientes de RUM do fornecedor, o que a página divulga, e essa população pende para organizações que já investem em medição de performance.

Everts também divulga a substituição de métrica: usou taxa de rejeição em vez de taxa de conversão porque a maioria das ferramentas de RUM captura isso por padrão, sem instrumentação adicional, e a trata como um bom proxy direcional. Direcional é a palavra honesta ali.

Os números por site vivem dentro de dez imagens de gráfico e não são extraíveis como texto, então as faixas agregadas acima são os números citáveis. Não existe um valor por varejista para citar, e inventar um repetiria o erro original em corpo menor.

O argumento sobrevive a tudo isso, porque se apoia numa observação estrutural: dez sites medidos individualmente discordaram do agregado nas duas direções. Estabelecer que uma estatística populacional falha em descrever indivíduos exige um contraexemplo limpo. Aqui há dez deles.

Agora conte quantas das suas métricas de governança são emprestadas

Leia o resultado de LCP como exemplo trabalhado de uma classe geral, e essa classe é desconfortavelmente grande em governança de IA.

“Percentual de código escrito por IA.” Toda versão publicada desse número vem da base de código de outra pessoa, com outro mix de linguagens e outra cultura de revisão. Já defendemos que o eixo de medição deveria ser a classe de autor e de revisor em vez de uma fração de linhas, e o problema do limiar emprestado é uma segunda razão. Se um fornecedor diz que 40% é onde estão os retornos, pergunte contra qual desfecho aquele 40% foi correlacionado, e em quais repositórios. Depois pergunte onde a sua própria curva achata. A maioria das organizações não sabe responder à segunda pergunta, o que significa que a primeira resposta está sendo aplicada às cegas.

Pisos de cobertura. Uma meta de 80% de cobertura é uma regra de bolso herdada de projetos com outro perfil de defeitos e outro raio de impacto. Em algum lugar da sua base de código existe um módulo em que 60% pega tudo que costuma quebrar, e outro em que 95% ainda entrega bug todo mês. O piso único trata os dois como o mesmo problema. É o caso dos quatro sites: passado certo ponto, o número para de prever escapes, e todo mundo continua escrevendo teste contra o número.

Regras de bolso de custo de CI. “Mantenha os pipelines abaixo de dez minutos” é uma afirmação sobre platô vestida de limiar. Nosso próprio trabalho de custo encontrou a contagem de jobs como o fator dominante, porque o GitHub arredonda cada job para um minuto inteiro, o que torna a sabedoria recebida sobre duração um previsor ruim da fatura. A regra de bolso foi medida sobre um formato de cobrança diferente do nosso.

SLAs de fornecedor e limiares de modelo. Já escrevemos sobre limiares dentro de decisões de precificação de modelo e sobre benchmarks que perdem sentido por contaminação. Este é um terceiro modo de falha, mais silencioso. O limiar é honesto, não contaminado, e simplesmente medido em uma população diferente daquela que o aplica. Ninguém agiu de má-fé. O número ainda engana.

Faça isto nas próximas duas semanas

Escolha o seu limiar mais estruturante. Aquele que aparece em slide de QBR, trava um release ou justifica uma linha de orçamento. Depois rode os quatro passos de Everts contra ele:

Puxe seus próprios dados da métrica, na granularidade que você já tem. Por sessão, se houver. Por PR, por deploy, por job.
Plote contra um desfecho que você realmente valoriza e já captura. Não instrumente nada novo para isso. O sentido da escolha da taxa de rejeição por ela foi justamente zero instrumentação extra.
Encontre onde o desfecho está genuinamente no melhor ponto, e encontre onde a sua curva achata.
Defina a meta sobre esses dois pontos, e não sobre um número derivado de milhões de sistemas que você não opera.

Se o gráfico mostrar que seu platô começa antes do limiar atual, você achou gasto que pode cessar. Se começa depois, você achou ganho que o painel escondia atrás de um selo verde. Qualquer um dos dois resultados vale mais do que o status de conformidade que você tem hoje, e nunca se deve assumir que cumprir um limiar externo está ajudando o seu negócio.

Produza o gráfico primeiro. Qualquer limiar que você anotar depois será, no mínimo, seu.

Fontes

Embrace / SpeedCurve. “New research: The Core Web Vitals thresholds you trust might be wrong for your site.” Julho de 2026.

A Victorino ajuda organizações de engenharia a substituir limiares emprestados por limiares medidos na própria telemetria: contato@victorino.com.br | www.victorino.com.br