Chrome deja de ejecutar el evento unload por defecto

La publicación oficial de Chrome confirma el cierre de un despliegue gradual que buscó reducir el riesgo de romper sitios existentes. A partir de Chrome 155, unload deja de dispararse por defecto incluso en situaciones en las que técnicamente podría hacerlo. El objetivo es retirar una señal que daba una falsa sensación de certeza sobre el final de una sesión de página.

Chrome informa que el uso de unload cayó del 18% de las navegaciones a menos del 4% durante el proceso. También señala que el evento pasó de ser el único bloqueo para bfcache en un 6% de las navegaciones a alrededor del 1%. Son cifras agregadas del navegador: sirven para dimensionar el cambio, pero no predicen el resultado de un sitio particular.

El riesgo principal recae sobre aplicaciones y sitios que todavía ejecutan trabajo crítico al abandonar la página. Entre los casos habituales están el envío final de eventos de analítica, la persistencia de formularios o estado de interfaz, y la liberación de conexiones o recursos. Si la lógica depende exclusivamente de unload, puede dejar de ocurrir sin mostrar un error visible al usuario.

Para publishers y equipos de monetización, la revisión también debe incluir etiquetas, librerías de medición y componentes de terceros. Una dependencia puede estar fuera del código principal y aun así alterar conteos de sesión, eventos de salida o procesos de reconciliación. La deprecación no demuestra por sí sola que una caída de datos provenga de unload; esa relación debe verificarse con instrumentación y pruebas controladas.

Chrome conserva mecanismos de excepción mediante Permissions Policy y políticas empresariales. Esos opt-outs pueden dar tiempo para migrar, pero no vuelven confiable al evento y el equipo de Chrome recomienda dejar de depender de él. Tampoco debe asumirse que el comportamiento es idéntico en todos los navegadores: Chrome para iOS utiliza WebKit y allí unload todavía puede ejecutarse.

beforeunload no es un reemplazo general. Tiene un propósito diferente —por ejemplo, advertir sobre cambios sin guardar— y también puede no dispararse si el sistema termina una pestaña en segundo plano. Para guardar datos o estado, Chrome recomienda evaluar visibilitychange cuando el documento pasa a hidden; para detectar una navegación, pagehide suele ser una alternativa más compatible con bfcache. La elección depende del trabajo que deba realizarse.

La migración conviene tratarla como una auditoría de comportamiento y de datos, no como un reemplazo textual de un nombre de evento. Primero hay que identificar qué intenta garantizar cada listener; luego elegir una señal coherente con ese objetivo y comprobar qué sucede cuando una página se oculta, se restaura desde bfcache, se cierra o es descartada por el sistema.

Para envíos de analítica, la prueba debería comparar volumen, duplicación y latencia antes y después del cambio. Para estado de aplicación, debe validarse que una restauración desde bfcache no reabra recursos en una condición inconsistente. Chrome DevTools incluye una prueba de Back/forward cache, y la propiedad notRestoredReasons de PerformanceNavigationTiming puede aportar evidencia sobre bloqueos observados en navegación real.

La deprecación de unload es, ante todo, un problema de integridad operacional. Un listener que deja de ejecutarse puede degradar métricas o persistencia sin producir una falla evidente, mientras que una migración apresurada puede duplicar señales al combinar varios eventos del ciclo de vida.

La oportunidad está en convertir una dependencia histórica en un contrato observable: definir qué dato debe sobrevivir, en qué momento puede enviarse, cómo se evita la duplicación y qué evidencia confirma que bfcache funciona. Ese enfoque separa la corrección técnica de la simple compatibilidad aparente y permite evaluar el cambio con métricas propias.