Speculation Rules e Prerendering: O Que a Analytics Erra Sobre Páginas Pré-carregadas
A API Speculation Rules do Chrome pode renderizar uma página antes mesmo de o usuário clicar. Veja como isso distorce análises ingênuas — e como a medição sem cookies, baseada na edge, permanece honesta.
A página que carregou antes do clique
A API Speculation Rules, agora amplamente disponível nos navegadores Chromium, permite que um site declare quais URLs o navegador deve pré-carregar (prefetch) ou renderizar totalmente (prerender) antes da navegação. Quando um usuário passa o mouse ou demonstra intenção, o destino já pode estar renderizado em uma aba oculta, e então ser trocado instantaneamente. O ganho é um Largest Contentful Paint próximo de zero na ativação. O problema, para a medição, é que uma página pré-renderizada executa seus scripts antes de alguém ter decidido visitá-la.
Se a sua analytics dispara um pageview no carregamento, o prerendering infla suas contagens com visitas que nunca aconteceram. Pior ainda, ele distorce os dados de desempenho: uma página pré-renderizada em segundo plano registra tempos que não têm relação alguma com o que um usuário real experimentou.
O que realmente acontece durante o prerender
Um documento pré-renderizado executa normalmente, mas em um estado especial de ciclo de vida. document.prerendering é true, e a página ainda não foi ativada na aba visível. O evento prerenderingchange dispara quando — e somente se — o usuário efetivamente navegar até ela. Muitos prerenders nunca são ativados; o navegador pode descartá-los.
Isso importa por dois motivos:
- Contagem. Um
sendBeaconingênuo noDOMContentLoadedvai reportar um pageview para um documento que talvez nunca seja visto. - Atribuição de desempenho. Os Core Web Vitals são definidos em relação ao carregamento percebido pelo usuário. A biblioteca web-vitals e as especificações subjacentes de Paint Timing e Event Timing levam o prerender em conta medindo a partir do ponto de ativação, e não do início da navegação original. Uma métrica coletada sem essa consciência está simplesmente errada.
O padrão correto
A plataforma web oferece sinais claros. Adie qualquer medição até que a página esteja genuinamente visível para uma pessoa:
if (document.prerendering) {
document.addEventListener('prerenderingchange', recordPageview, { once: true });
} else {
recordPageview();
}
Para o tempo, PerformanceNavigationTiming.activationStart fornece o deslocamento entre o início da navegação e a ativação. Qualquer timestamp de paint ou interação deve ser medido em relação a esse valor, limitando os negativos a zero. É exatamente isso que a biblioteca web-vitals do Google faz internamente, então, se você calcular LCP ou INP por conta própria, reproduza essa lógica.
A mesma disciplina se aplica ao prefetch, o primo mais leve do prerender. O prefetch apenas busca a resposta; ele não executa scripts, então raramente polui a analytics diretamente. Mas ele consome banda e pode distorcer os logs de requisições do lado do servidor — um lembrete de que a contagem bruta de logs e as visitas genuínas divergem mais do que nunca.
Por que isso é mais fácil sem cookies ou estado no cliente
O prerender orientado por especulação é uma dor de cabeça para rastreadores com estado. Um documento pré-renderizado que define identificadores, hidrata uma sessão ou grava no armazenamento faz isso de forma especulativa — para uma visita que pode ser descartada. Limpar tudo isso, deduplicar em relação à eventual ativação real e reconciliar a identidade entre páginas se torna uma fonte genuína de erro e de risco à privacidade.
A Monoid contorna toda essa classe de problema. Não armazenamos nada no dispositivo — sem cookies, sem localStorage, sem fingerprint. Não há sessão especulativa para criar e depois descriar. A medição é um único sinal, sem estado, que só emitimos quando a página é real. Como a coleta roda na edge da Cloudflare, a agregação acontece sobre dados que já refletem navegações genuínas e ativadas, em vez dos palpites otimistas de um navegador.
Isso é a minimização de dados trabalhando a seu favor. Quando você não coleta nada que precise ser limpo, a renderização especulativa não cria registros de identidade órfãos nem perfis duplicados. Ela apenas significa que você espera pelo prerenderingchange antes de contar.
Uma checklist para analytics segura para prerender
- Condicione a emissão de pageview ao
document.prerenderinge ao eventoprerenderingchange. - Calcule LCP, FCP e INP em relação ao
activationStart, ou use uma biblioteca que já faça isso. - Trate os logs de requisições do servidor como um superconjunto das visitas reais, e não como um substituto delas.
- Confirme que sua Content-Security-Policy permite que o seu endpoint de medição seja alcançado a partir de um documento ativado; teste no painel de prerender do Chrome DevTools.
- Evite quaisquer gravações especulativas no armazenamento do dispositivo — a maneira mais limpa de estar correto em relação ao prerender é não manter nenhum estado no cliente.
O ponto mais amplo
Cada nova primitiva de desempenho — bfcache, soft navigations e agora as speculation rules — quebra silenciosamente a velha premissa de que um carregamento de página equivale a uma visita humana. Uma analytics que se apoia em cookies e sessões com estado precisa acoplar cada vez mais lógica de reconciliação. Uma analytics que mede um evento sem estado no momento da visibilidade genuína só precisa respeitar os eventos de ciclo de vida da plataforma. Páginas mais rápidas e números honestos não estão em conflito; você só precisa contar no momento certo.
Comments
Loading comments…