Google anunció hace unos meses que su navegador Chrome eliminará gradualmente el soporte para el evento unload.
Este evento existe desde los albores de la Web, hace casi 30 años, y durante varias décadas ha sido una herramienta común para ejecutar código cuando el usuario abandona una página. Ahora se va a ir desactivando progresivamente hasta su completa eliminación en el segundo trimestre de 2025.
Este tipo de código:
// Código que pronto dejará de funcionar
window.addEventListener('unload', () => {
// Guardar datos
localStorage.setItem('ultimaVisita', new Date().toISOString());
// Limpiar recursos
conexion.cerrar();
// Enviar analíticas
navigator.sendBeacon('/analytics', datos);
});
es muy común en aplicaciones web existentes y se ha utilizado tradicionalmente para:
- Guardar el estado de la aplicación antes de que el usuario abandone la página
- Cerrar conexiones y liberar recursos
- Enviar datos de analítica sobre el uso de la página
- Realizar tareas de limpieza final
Sin embargo, existe un problema fundamental: el evento unload nunca ha sido fiable. En dispositivos móviles, donde las pestañas se cierran muy a menudo en segundo plano, el evento no se dispara. Además, su uso impide que el navegador pueda implementar optimizaciones importantes, como la caché de navegación hacia atrás/adelante (bfcache).
El cambio comenzó a gestarse en enero de 2019, cuando el equipo de Chrome anunció su intención de implementar la bfcache. Desde entonces, el uso de este evento ha ido disminuyendo poco a poco, pero todavía quedan muchos sitios web que dependen de unload.
La buena noticia es que existen alternativas más modernas y fiables que veremos en detalle más adelante. Pero antes, es importante entender por qué se ha tomado esta decisión y qué implica para el desarrollo web moderno.
Razones para eliminar el evento unload
La Web ha evolucionado mucho desde que se introdujo este evento unload. Lo que antes era un ecosistema dominado por ordenadores de escritorio, ahora es un mundo multiplataforma donde los dispositivos móviles son mucho más abundantes.
Esta realidad choca de frente con el concepto básico detrás del evento unload: la idea de que podemos detectar de forma fiable cuándo un usuario abandona nuestra página. En el mundo actual dominado por los móviles y otros dispositivos que no cierran las aplicaciones, simplemente ya no es verdad.
Existen varios motivos para que esto no sea ya operativo:
1.- El mito del "abandono de página"
// Este código asume un mundo que ya no existe
window.addEventListener('unload', () => {
// Asumimos que el usuario está "abandonando" la página
// pero... ¿realmente está sucediendo eso?
sincronizarDatosAntesDeIrnos(); // ¿Llegará a ejecutarse?
});
Pensemos en situaciones cotidianas:
- Un usuario cambia de pestaña y el sistema operativo decide congelar la página para ahorrar memoria (esto pasa también en el escritorio hace años)
- Alguien cierra la aplicación del navegador directamente desde el gestor de tareas (tanto móvil, que es muy habitual, como en el ordenador).
- Un navegador móvil mata pestañas en segundo plano sin previo aviso para ahorrar recursos
- El móvil se pone en modo ahorro de batería
En ninguno de estos casos se dispara de forma fiable el evento unload .
2.- Caché de navegación anulada
Pero hay más: el simple hecho de registrar un evento unload tiene efectos negativos en el rendimiento de la navegación:
- Impide que la página pueda ser guardada en la mencionada caché de navegación hacia atrás/adelante (bfcache)
- Esto significa que cada vez que el usuario navega hacia atrás o adelante, la página debe recargarse por completo
El resultado: más consumo de datos, más tiempo de carga y peor experiencia de usuario
3.- La trampa de la falsa seguridad
El mayor problema del evento unload es que da una falsa sensación de control sobre el ciclo de vida de la aplicación. Muchos desarrolladores confían en él para tareas críticas, cuando en realidad, aunque en Chrome, Firefox y otros navegadores de escritorio ha sido relativamente fiable (hasta ahora):
- En navegadores móviles casi nunca se ejecuta
- Safari ya hace tiempo que hace caso omiso de él en favor de la bfcache, tanto en móvil como en escritorio
Esta inconsistencia entre plataformas y navegadores nos ha traído ya hace años bugs sutiles y comportamientos inesperados que son difíciles de depurar (nosotros mismos los sufrimos hace años en nuestra plataforma SELF, que es la que usamos para campusMVP.es).
La decisión de eliminar el evento unload no es, por tanto, un capricho: es algo que deberíamos ya eliminar nosotros mismos de nuestro código, adaptando nuestros desarrollos a la realidad de la web moderna. Una web donde el concepto de "abandonar una página" es mucho más fluido y menos predecible de lo que solíamos ser hace 15 años.
Alternativas recomendadas para reemplazar al evento unload
La eliminación del evento unload no significa que nos quedemos sin opciones para gestionar el ciclo de vida de nuestras páginas. Es más, en realidad tenemos varias alternativas, que además son más robustas y fiables.
Veamos cómo podemos reemplazar los casos de uso más comunes.
El evento visibilitychange
Este va a ser tu nuevo mejor amigo para detectar cuándo el usuario deja de interactuar con la página. Vamos a verlo con un ejemplo sencillo:
// Forma moderna de guardar el estado de la aplicación
document.addEventListener('visibilitychange', () => {
if (document.hidden) {
// El usuario no está viendo la página
// ¡Este es un momento fiable para guardar datos!
guardarEstado();
pausarAnimaciones();
detenerActualizacionesEnVivo();
} else {
// ¡El usuario ha vuelto!
reanudarAnimaciones();
actualizarDatos();
}
});
Este evento visibilitychange se activa cuando el estado de visibilidad de una página web cambia, es decir, cuando el usuario navega entre pestañas o minimiza/maximiza la ventana del navegador. En móviles también cuando manda a segundo plano el navegador.
Gracias a él, podemos detectar si la página está visible o no, lo que es útil para pausar o reanudar actividades como la reproducción de vídeos, animaciones (que no aportan nada si nadie mira), la actualización de datos o la gestión de recursos, optimizando así el rendimiento y la experiencia del usuario.
La propiedad document.visibilityState, puede tener los valores "visible" o "hidden"para indicar el estado actual de visibilidad de la página.
El evento pagehide
El evento pagehide se dispara cuando una página está a punto de ser ocultada (justo antes), ya sea porque el usuario navega a otro lado, cierra la pestaña o la ventana, o cambia a otra pestaña en el navegador. Este evento es parte de la API de navegación y se utiliza para realizar tareas de limpieza o guardar el estado de la aplicación antes de que la página se oculte. Es perfecto para detectar navegaciones reales.
Para implementarlo, se añade un listener para el vento en el objeto window y dentro de la función manejadora se pueden ejecutar las acciones necesarias antes de que la página se oculte:
window.addEventListener('pagehide', (event) => {
// event.persisted nos dice si la página podría
// restaurarse desde la bfcache
if (!event.persisted) {
// Hacemos lo necesario
}
// En todos los casos enviamos analíticas
navigator.sendBeacon('/analytics', recopilarMetricas());
});
Inciso: ¿qué pasa con los cambios sin guardar?
Si necesitas advertir al usuario sobre cambios sin guardar, el evento beforeunload sigue siendo válido, pero úsalo con moderación:
let hayCambiosSinGuardar = false;
// Añade el listener solo cuando hay cambios
formulario.addEventListener('input', () => {
if (!hayCambiosSinGuardar) {
hayCambiosSinGuardar = true;
window.addEventListener('beforeunload', confirmarSalida);
}
});
function confirmarSalida(e) {
if (hayCambiosSinGuardar) {
e.preventDefault();
} else {
window.removeEventListener('beforeunload', confirmarSalida);
}
}
// Cuando el usuario guarda, eliminamos la advertencia
formulario.addEventListener('submit', () => {
hayCambiosSinGuardar = false;
window.removeEventListener('beforeunload', confirmarSalida);
});
Resumen de alternativas al evento "unload" según la casuística
Estas alternativas no solo son más fiables, sino que también permiten que tu aplicación aproveche características modernas como la bfcache, mejorando de paso la experiencia de usuario.
Plan de eliminación y fechas clave
¿Y cuándo se eliminará definitivamente el evento unload?
Bueno, no será inmediato, pero hay que ir preparándose para que no nos pille el toro. Aunque, como ya dije al principio, en realidad deberías tener las apps adaptadas hace ya mucho tiempo.
Las fases son las siguientes:
Fase 1: Los grandes sitios
El proceso comenzó con los 50 sitios web más visitados del mundo:
- Noviembre 2023 (Chrome 120): el evento dejó de funcionar para el 1% de los usuarios
- Durante 2024: el porcentaje irá aumentando gradualmente
- Tercer trimestre de 2024: llegó al 100% de los usuarios para estos sitios. O sea, ahora mismo ya no funciona en estos sitios web.
Fase 2: El resto de la web
A partir de finales de 2024, la eliminación se extenderá a todos los sitios web:
- Comenzará con un 1% de usuarios
- Primer trimestre de 2025: se eliminará poco a poco para el 100% de los usuarios
- A partir del segundo trimestre de 2025: eliminación completa
Conclusiones finales
El evento unload ha llegado a su fin después de casi 30 años de existencia. Su desaparición no es un capricho, sino una necesaria adaptación a la web moderna, caracterizada por dispositivos móviles, navegación más dinámica y la necesidad de optimizar el rendimiento de las aplicaciones web.
Las alternativas como visibilitychange y pagehide ofrecen soluciones más robustas y fiables para los casos de uso tradicionales del evento unload. Los desarrolladores debemos migrar gradualmente nuestro código (si no lo hemos ya), aprovechando estas APIs más flexibles y adecuadas para las características de los navegadores actuales.
La transición será paulatina, con una eliminación completa prevista para el segundo trimestre de 2025. Es crucial que los equipos de desarrollo actualicen sus aplicaciones web cuanto antes para garantizar la compatibilidad y un funcionamiento óptimo en los navegadores modernos.