Caso

A derrocada do INP

Uma campanha de performance que conduzi na Seox em 20 portais WordPress, da investigação na thread principal às mudanças no Publisher.

Métrica Antes Depois Δ
Mediana p75 mobile 287,5ms 137,5ms −52%
Portais aprovados 6/20 15/20 +45 p.p.

Quatorze portais acima do limite

Durante minha atuação na Seox, conduzi esta campanha de performance em 20 portais clientes que rodavam no Publisher, a plataforma da empresa. Em março de 2025, 14 deles estavam acima de 200 ms no p75 mobile. A mediana da frota era 287,5 ms. O problema aparecia no campo, depois de dias de uso real, mesmo quando o Lighthouse parecia bom.

Em portal de notícia, um clique divide a thread principal com menu, player, publicidade, consentimento, Analytics e tudo o que a página acumula para funcionar e faturar. O CrUX registra essa experiência numa janela móvel de 28 dias. Uma execução isolada do PageSpeed não dava conta do diagnóstico.

A thread principal tinha dono demais

Naquela época, o Google já havia adotado o INP no lugar do FID. Muitos portais passaram a reprovar na avaliação de Core Web Vitals porque ainda não tinham se ajustado à nova métrica. Eu validava os resultados no CrUX, em mais de um tipo de página. Em 2025, o volume de portais acima do limite virou uma campanha de produto.

Passei portal por portal cruzando CrUX, traces do DebugBear e execução de scripts. O padrão se repetia: listeners demais, código de medição carregado cedo, GTM segurando Analytics e terceiros brigando pela thread principal no momento do clique.

Desativamos addons que já custavam mais do que entregavam, mudamos a forma de servir o GA4, removemos GTM onde ele não era necessário e abrimos uma frente específica para anúncios, navbars, modal e leitor de notícias.

O diagnóstico virou produto

A equipe levou parte das correções para a própria plataforma. O Publisher 3.1 descontinuou os addons GDL e CWV com objetivo explícito de melhorar o INP e mudou a entrega do Google Analytics para reduzir o peso do GTM. O Publisher 3.2 levou as otimizações para Ads, Modal, Navbars e News Reader.

De 287,5 para 137,5 ms

Para comparar os períodos sem trocar a amostra no caminho, usei os mesmos 20 clientes em março e outubro de 2025. Todos já eram clientes antes da campanha e tinham p75 mobile disponível nos dois meses.

Entre março e outubro de 2025, a mediana do p75 mobile caiu de 287,5 para 137,5 ms, uma redução de 52%. Os portais na faixa aprovada, com INP ≤ 200 ms, passaram de 6 para 15 dentro da mesma frota.

MêsPortais medidosPortais aprovadosMediana p75
Mar/2025206287,5 ms
Out/20252015137,5 ms

No detalhe, 19 dos 20 melhoraram. Um ficou estável.

Depois do verde

As datas das versões e a curva mostram associação, não prova causal isolada. Publicidade, consentimento, mudanças comerciais e o ritmo de rollout também mexem no resultado.

Em portal com ads, qualquer script novo pode devolver custo à thread principal. Por isso o INP continuou na rotina depois do deploy: medir, localizar a interação, atribuir o componente e validar de novo no campo.