Speculation Rules e Prerendering: cosa sbagliano gli strumenti di analytics riguardo alle pagine precaricate
La Speculation Rules API di Chrome può renderizzare una pagina prima ancora che l'utente faccia clic. Ecco come distorce gli analytics ingenui — e come una misurazione cookieless, basata sull'edge, rimane onesta.
La pagina che si è caricata prima del clic
La Speculation Rules API, ora ampiamente distribuita nei browser Chromium, consente a un sito di dichiarare quali URL il browser dovrebbe prefetchare o renderizzare completamente in anticipo rispetto alla navigazione. Quando un utente passa il mouse o manifesta un'intenzione, la destinazione può essere già renderizzata in una scheda nascosta e poi sostituita istantaneamente. Il vantaggio è un Largest Contentful Paint prossimo allo zero al momento dell'attivazione. Il problema, per la misurazione, è che una pagina prerenderizzata esegue i tuoi script prima che qualcuno abbia deciso di visitarla.
Se i tuoi analytics registrano una pageview al caricamento, il prerendering gonfia i tuoi conteggi con visite che non sono mai avvenute. Peggio ancora, distorce i dati di performance: una pagina prerenderizzata in background registra tempistiche che non hanno alcuna relazione con ciò che un utente reale ha effettivamente sperimentato.
Cosa succede davvero durante il prerender
Un documento prerenderizzato viene eseguito normalmente, ma in uno stato del ciclo di vita speciale. document.prerendering è true, e la pagina non è ancora stata attivata nella scheda visibile. L'evento prerenderingchange si attiva quando — e solo se — l'utente naviga effettivamente verso di essa. Molti prerender non vengono mai attivati; il browser può scartarli.
Questo è importante per due motivi:
- Conteggio. Un ingenuo
sendBeaconsuDOMContentLoadedregistrerà una pageview per un documento che potrebbe non essere mai visto. - Attribuzione delle performance. I Core Web Vitals sono definiti rispetto al caricamento percepito dall'utente. La libreria web-vitals e le specifiche sottostanti di Paint Timing ed Event Timing tengono conto del prerender misurando dal punto di attivazione, non dall'inizio della navigazione originale. Una metrica raccolta senza questa consapevolezza è semplicemente sbagliata.
Lo schema corretto
La piattaforma web ti offre segnali puliti. Rimanda qualsiasi misurazione finché la pagina non è realmente visibile a una persona:
if (document.prerendering) {
document.addEventListener('prerenderingchange', recordPageview, { once: true });
} else {
recordPageview();
}
Per le tempistiche, PerformanceNavigationTiming.activationStart fornisce lo scarto tra l'inizio della navigazione e l'attivazione. Qualsiasi timestamp di paint o interazione dovrebbe essere misurato rispetto a quel valore, azzerando i valori negativi. È esattamente ciò che la libreria web-vitals di Google fa internamente, quindi se calcoli LCP o INP autonomamente, replica quella logica.
La stessa disciplina si applica al prefetch, il cugino più leggero del prerender. Il prefetch recupera soltanto la risposta; non esegue gli script, quindi raramente inquina direttamente gli analytics. Ma consuma comunque banda e può falsare i log delle richieste lato server — un promemoria del fatto che i conteggi grezzi dei log e le visite reali divergono più che mai.
Perché è più facile senza cookie o stato client
Il prerender guidato dalla speculazione è un grattacapo per i tracker con stato. Un documento prerenderizzato che imposta identificatori, idrata una sessione o scrive nello storage lo fa in modo speculativo — per una visita che potrebbe essere scartata. Ripulire tutto ciò, deduplicare rispetto all'eventuale attivazione reale e riconciliare l'identità tra le pagine diventa una genuina fonte di errore e di rischio per la privacy.
Monoid aggira l'intera categoria di problema. Non memorizziamo nulla sul dispositivo — nessun cookie, nessun localStorage, nessun fingerprint. Non c'è alcuna sessione speculativa da creare e poi eliminare. La misurazione è un singolo segnale privo di stato che emettiamo solo una volta che la pagina è reale. Poiché la raccolta avviene all'edge di Cloudflare, l'aggregazione lavora su dati che riflettono già navigazioni genuine e attivate, anziché le previsioni ottimistiche di un browser.
Questa è la minimizzazione dei dati che lavora a tuo favore. Quando non raccogli nulla che debba essere ripulito, il rendering speculativo non crea record di identità orfani o profili duplicati. Significa semplicemente che aspetti prerenderingchange prima di contare.
Una checklist per analytics a prova di prerender
- Vincola l'emissione della pageview a
document.prerenderinge all'eventoprerenderingchange. - Calcola LCP, FCP e INP rispetto a
activationStart, oppure usa una libreria che lo faccia già. - Considera i log delle richieste del server come un sovrainsieme delle visite reali, non come loro surrogato.
- Verifica che la tua Content-Security-Policy consenta di raggiungere il tuo endpoint di misurazione da un documento attivato; testa nel pannello prerender di Chrome DevTools.
- Evita qualsiasi scrittura speculativa nello storage del dispositivo — il modo più pulito per essere corretti rispetto al prerender è non mantenere alcuno stato client.
Il punto più ampio
Ogni nuova primitiva di performance — bfcache, soft navigations e ora le speculation rules — infrange silenziosamente la vecchia assunzione secondo cui un caricamento di pagina equivale a una visita umana. Gli analytics che si appoggiano ai cookie e alle sessioni con stato devono aggiungere sempre più logica di riconciliazione. Gli analytics che misurano un evento privo di stato nel momento della visibilità genuina devono semplicemente rispettare gli eventi del ciclo di vita della piattaforma. Pagine più veloci e numeri onesti non sono in contraddizione; devi soltanto contare nel momento giusto.
Comments
Loading comments…