Reglas de especulación y prerenderizado: qué se equivoca la analítica con las páginas precargadas
La API de Speculation Rules de Chrome puede renderizar una página antes de que el usuario haga clic. Así es como distorsiona la analítica ingenua — y cómo la medición sin cookies y basada en el edge se mantiene honesta.
La página que se cargó antes del clic
La API de Speculation Rules, ahora ampliamente disponible en los navegadores Chromium, permite que un sitio declare qué URLs debe precargar o prerenderizar por completo el navegador antes de la navegación. Cuando un usuario pasa el cursor o muestra intención, el destino ya puede estar renderizado en una pestaña oculta y luego intercambiarse al instante. La recompensa es un Largest Contentful Paint casi nulo en el momento de la activación. El problema, para la medición, es que una página prerenderizada ejecuta tus scripts antes de que nadie haya decidido visitarla.
Si tu analítica dispara una vista de página al cargar, el prerenderizado infla tus recuentos con visitas que nunca ocurrieron. Peor aún, distorsiona los datos de rendimiento: una página prerenderizada en segundo plano registra tiempos que no guardan ninguna relación con lo que experimentó un usuario real.
Qué ocurre realmente durante el prerenderizado
Un documento prerenderizado se ejecuta con normalidad, pero en un estado especial del ciclo de vida. document.prerendering es true, y la página aún no se ha activado en la pestaña visible. El evento prerenderingchange se dispara cuando — y solo si — el usuario realmente navega hacia ella. Muchos prerenderizados nunca se activan; el navegador puede descartarlos.
Esto importa por dos razones:
- Recuento. Un
sendBeaconingenuo enDOMContentLoadedreportará una vista de página para un documento que quizá nunca se vea. - Atribución de rendimiento. Los Core Web Vitals se definen en relación con la carga percibida por el usuario. La biblioteca web-vitals y las especificaciones subyacentes de Paint Timing y Event Timing tienen en cuenta el prerenderizado al medir desde el punto de activación, no desde el inicio de la navegación original. Una métrica recopilada sin esa consideración es simplemente errónea.
El patrón correcto
La plataforma web te ofrece señales claras. Aplaza cualquier medición hasta que la página sea genuinamente visible para una persona:
if (document.prerendering) {
document.addEventListener('prerenderingchange', recordPageview, { once: true });
} else {
recordPageview();
}
Para el tiempo, PerformanceNavigationTiming.activationStart proporciona el desfase entre el inicio de la navegación y la activación. Cualquier marca de tiempo de pintado o interacción debe medirse en relación con ese valor, ajustando los negativos a cero. Esto es exactamente lo que hace internamente la biblioteca web-vitals de Google, así que si calculas LCP o INP por tu cuenta, replica esa lógica.
La misma disciplina se aplica al prefetch, el primo más ligero del prerenderizado. El prefetch solo obtiene la respuesta; no ejecuta scripts, por lo que rara vez contamina la analítica directamente. Pero sí consume ancho de banda y puede sesgar los registros de solicitudes del lado del servidor — un recordatorio de que los recuentos brutos de logs y las visitas genuinas divergen más que nunca.
Por qué esto es más fácil sin cookies ni estado en el cliente
El prerenderizado impulsado por especulación es un quebradero de cabeza para los rastreadores con estado. Un documento prerenderizado que establece identificadores, hidrata una sesión o escribe en el almacenamiento lo hace de forma especulativa — para una visita que puede descartarse. Limpiar eso, deduplicar frente a la eventual activación real y reconciliar la identidad entre páginas se convierte en una fuente genuina de error y riesgo para la privacidad.
Monoid esquiva por completo toda esta clase de problema. No almacenamos nada en el dispositivo — ni cookies, ni localStorage, ni huella digital. No hay ninguna sesión especulativa que crear y luego deshacer. La medición es una única señal sin estado que solo emitimos cuando la página es real. Como la recopilación se ejecuta en el edge de Cloudflare, la agregación ocurre sobre datos que ya reflejan navegaciones genuinas y activadas, en lugar de las conjeturas optimistas de un navegador.
Esto es la minimización de datos trabajando a tu favor. Cuando no recopilas nada que haya que limpiar, el renderizado especulativo no crea registros de identidad huérfanos ni perfiles duplicados. Simplemente significa esperar a prerenderingchange antes de contar.
Una lista de comprobación para una analítica segura frente al prerenderizado
- Condiciona la emisión de vistas de página a
document.prerenderingy al eventoprerenderingchange. - Calcula LCP, FCP e INP en relación con
activationStart, o usa una biblioteca que ya lo haga. - Trata los registros de solicitudes del servidor como un superconjunto de las visitas reales, no como un sustituto de ellas.
- Confirma que tu Content-Security-Policy permite acceder a tu endpoint de medición desde un documento activado; pruébalo en el panel de prerenderizado de Chrome DevTools.
- Evita cualquier escritura especulativa en el almacenamiento del dispositivo — la forma más limpia de ser correcto frente al prerenderizado es no mantener ningún estado en el cliente.
El punto más amplio
Cada nueva primitiva de rendimiento — bfcache, navegaciones suaves y ahora las reglas de especulación — rompe silenciosamente la vieja suposición de que una carga de página equivale a una visita humana. La analítica que se apoya en cookies y sesiones con estado tiene que añadir cada vez más lógica de reconciliación. La analítica que mide un evento sin estado en el momento de la visibilidad genuina solo necesita respetar los eventos del ciclo de vida de la plataforma. Las páginas más rápidas y las cifras honestas no están en conflicto; simplemente hay que contar en el momento adecuado.
Comments
Loading comments…