Por qué beforeunload vs pagehide decide si tus analíticas sobreviven

¿Por qué importa beforeunload vs pagehide para enviar analíticas?

Elegir correctamente entre beforeunload vs pagehide decide si un evento de analíticas llega realmente al servidor antes de que un usuario abandone la página. MDN documenta que beforeunload no se dispara de forma fiable, sobre todo en móvil: un usuario que cambia a otra app y más tarde cierra el navegador desde el gestor de apps nunca llega a disparar el evento. Usa pagehide o visibilitychange para enviar datos en lugar de beforeunload, y reserva beforeunload para la única tarea que todavía cumple bien, avisar a un usuario de cambios sin guardar. Hacer esto mal es una de las razones más silenciosas por las que una configuración de monitorización de usuarios reales subcuenta las salidas.

¿Qué hace realmente el evento beforeunload?

El evento beforeunload se dispara justo antes de que una página se descargue y puede mostrar un cuadro de diálogo de confirmación nativo del navegador para avisar a un usuario de cambios sin guardar. La propia guía de MDN recomienda añadir el listener solo cuando hay cambios sin guardar que proteger, y quitarlo en cuanto esos cambios se guardan, en lugar de dejarlo enganchado durante toda la vida de la página. Ese caso de uso concreto es también el único para el que sigue siendo adecuado, ya que su fiabilidad como señal de salida general no existe.

¿Por qué beforeunload es poco fiable en móvil?

Beforeunload es poco fiable en móvil porque un navegador cerrado desde el selector de apps, o una app que pasa a segundo plano y nunca se vuelve a abrir, se salta el evento por completo, algo que MDN señala directamente con el escenario de cambiar de app y luego cerrar. Una pestaña de escritorio cerrada con los controles de la ventana dispara el evento; la misma secuencia en un teléfono, enviar la app a segundo plano y cerrarla desde el gestor de apps, se salta el evento por completo. Cualquier llamada de analíticas que dependa únicamente de que se dispare beforeunload pierde datos justo en la plataforma donde las sesiones terminan así.

Mismo cierre, resultado distinto

Cierre de pestaña en escritorio

• El usuario hace clic en los controles de la ventana
• beforeunload se dispara

Cambio de app en móvil

• El usuario envía la app a segundo plano y luego la cierra desde el gestor de apps
• beforeunload nunca se dispara

¿Cómo afecta beforeunload al back-forward cache?

El efecto de beforeunload sobre el back-forward cache varía según el navegador: Firefox no coloca una página en el bfcache si tiene un listener de beforeunload enganchado, mientras que la guía de bfcache de web.dev señala que beforeunload ya no descalifica a una página del bfcache en otros navegadores modernos, aunque antes sí lo hacía. Web.dev sigue llamando al evento "poco fiable, así que evita usarlo salvo que sea absolutamente necesario", y recomienda añadir el listener de forma condicional, solo mientras existan cambios sin guardar, en lugar de en cada carga de página. Una página que se salta el bfcache se recarga desde cero en una navegación hacia atrás en vez de restaurarse al instante desde memoria.

¿Qué hace de forma distinta el evento pagehide?

El evento pagehide se dispara cuando el navegador oculta la página actual mientras presenta otra página del historial de sesión, como al pulsar el botón de atrás, y a diferencia de beforeunload y unload, un listener de pagehide no hace que una página quede inelegible para el bfcache. MDN recomienda visibilitychange primero como la señal más fiable, con pagehide como respaldo para los navegadores donde visibilitychange no está disponible. Engancha la lógica de envío a pagehide cuando una página necesite un listener seguro para el bfcache que aun así se dispare en los mismos momentos de navegación que beforeunload pretendía capturar, que es también el momento en que un reloj de tiempo de espera de sesión seguiría corriendo contra una página que nadie está mirando.

Evento	¿Se dispara de forma fiable en móvil?	¿Bloquea el bfcache?	Mejor uso
unload	No, MDN lo llama "extremadamente poco fiable" en móvil	Sí, en Chrome y Firefox de escritorio	Evitar; solo código heredado
beforeunload	No, según el ejemplo de cambio de app de MDN	No en navegadores modernos, según web.dev	Solo avisar de cambios sin guardar
pagehide	Señal de respaldo según MDN	No	Enviar analíticas cuando visibilitychange no está disponible
visibilitychange	Señal principal recomendada por MDN	No	Enviar analíticas al ocultar la pestaña, primera opción

¿Dónde encaja sendBeacon junto a pagehide?

sendBeacon encaja junto a pagehide como el mecanismo de entrega, ya que encola una solicitud POST asíncrona que el navegador sigue intentando enviar aunque la página desaparezca, sin retrasar la navegación que el usuario ya está haciendo. MDN recomienda combinarlo con el evento visibilitychange como disparador principal y pagehide como respaldo, en lugar de dispararlo desde unload o beforeunload. Una sola llamada a sendBeacon tiene un límite de unos 64 KiB; una carga mayor necesita fetch() con la opción keepalive en su lugar.

¿Cómo debería un script de analíticas combinar estos eventos?

Un script de analíticas debería escuchar visibilitychange y comprobar document.visibilityState === "hidden" como disparador principal de envío, añadir pagehide como respaldo para navegadores o situaciones donde visibilitychange no se dispara, y llamar a sendBeacon en ambos manejadores para enviar la carga sin bloquear la navegación. El script ligero de Flowsery pesa menos de 10 KB precisamente para que esta lógica de listeners añada un peso insignificante a una página que ya está intentando irse. Saltar directo a beforeunload para esta tarea es el atajo que más datos cuesta en móvil, y es el mismo atajo que desinfla en silencio un recuento de tasa de rebote vs tasa de salida cuando el evento final de una página nunca llega al servidor.

Enviar analíticas antes de que una página desaparezca

1

Escuchar visibilitychange. Comprobar document.visibilityState === "hidden" como señal principal.

2

Añadir pagehide como respaldo. Cubre los casos donde visibilitychange no se dispara.

3

Enviar con sendBeacon. Encola un POST asíncrono que no retrasa la navegación.

4

Reservar beforeunload solo para cambios sin guardar. Añadirlo de forma condicional, quitarlo tras guardar.

Preguntas frecuentes

¿Sigue siendo útil beforeunload para algo?

Beforeunload sigue siendo útil para avisar a un usuario de cambios sin guardar mediante un cuadro de diálogo de confirmación nativo del navegador. La propia recomendación de MDN es enganchar el listener solo mientras existan cambios sin guardar y quitarlo en cuanto se guarden, en lugar de usarlo como señal general de salida de página.

¿Por qué pagehide no bloquea el back-forward cache como antes hacía beforeunload?

Pagehide no bloquea el bfcache porque se diseñó como parte de la Page Lifecycle API específicamente para señalar una transición de página sin los efectos secundarios que conllevan unload y beforeunload. MDN afirma claramente que, a diferencia de unload y beforeunload, un listener de pagehide no hace que una página quede inelegible para el bfcache.

¿Debería visibilitychange reemplazar por completo a pagehide?

Visibilitychange debería ser la señal principal, con pagehide mantenido como respaldo, según la propia guía de MDN. Algunos navegadores o contextos no disparan visibilitychange en todos los escenarios de salida, así que pagehide cubre los casos que visibilitychange se pierde en lugar de reemplazarlo del todo.

¿Qué pasa si una llamada de analíticas usa fetch en vez de sendBeacon al salir de la página?

Una llamada fetch normal iniciada durante la salida de la página puede cancelarse antes de que el navegador termine de enviarla, ya que la página ya se está descargando. sendBeacon existe precisamente para evitar eso: el navegador acepta la solicitud y sigue intentando entregarla independientemente de si la página ya ha desaparecido, hasta su límite de unos 64 KiB.

¿Afecta el back-forward cache a las analíticas en algo?

El back-forward cache restaura una página desde memoria en una navegación hacia atrás o hacia adelante en lugar de recargarla, lo que significa que el JavaScript de la página no se vuelve a ejecutar y cualquier lógica de vista de página que dependa de una carga nueva no se dispara de nuevo. Un evento pageshow con event.persisted === true es la señal de que ha ocurrido una restauración, algo que la lógica de analíticas necesita comprobar por separado de una primera carga.

¿Por qué Firefox trata beforeunload de forma distinta a otros navegadores para el bfcache?

Firefox descalifica a una página del bfcache si tiene un listener de beforeunload enganchado, una postura más estricta que la de navegadores que dejaron de descalificar páginas con beforeunload para el bfcache después de hacerlo antes. La opción más segura entre navegadores sigue siendo añadir un listener de beforeunload solo cuando existan cambios sin guardar, ya que eso mantiene el listener fuera de la página durante las navegaciones donde más importa la elegibilidad para el bfcache.

¿Qué pasa si una carga útil de analíticas supera el límite de 64 KiB de sendBeacon?

Una llamada a sendBeacon, limitada a unos 64 KiB, rechaza directamente una carga mayor, así que nunca llega al servidor. Cambiar a fetch con la opción keepalive gestiona cargas por encima de ese límite y sigue funcionando aunque la página ya esté descargándose.

¿Es el evento unload un respaldo más seguro que beforeunload?

Unload es peor, no más seguro. MDN lo califica de extremadamente poco fiable en móvil, y sigue bloqueando el back-forward cache en Chrome y Firefox de escritorio, justo el coste que pagehide busca evitar. Conviene tratarlo como código heredado que evitar, no como un respaldo al que recurrir.

¿Añadir listeners de pagehide y visibilitychange hace más pesada una página?

Flowsery entrega su script en menos de 10 KB precisamente para que esta lógica de listeners añada un peso insignificante a una página que ya está intentando salir. El coste real está en el tamaño de la carga de sendBeacon, no en los propios listeners.

¿Cómo afecta el envío en pagehide al seguimiento del tiempo de espera de sesión?

Pagehide se dispara justo en el momento en que una página queda oculta detrás de otra en el historial de sesión, que es también el momento en que un reloj de tiempo de espera de sesión seguiría corriendo contra una página que ya nadie mira. Enviar los datos ahí cierra la sesión en el instante correcto en lugar de acumular tiempo inactivo contra una pestaña que el usuario ya abandonó.