Si una aplicación todavía depende de unload para guardar estado, liberar recursos o enviar analytics, la migración ya no es solo preventiva. El calendario oficial de Chrome, actualizado por última vez el 14 de julio de 2026, indica que Chrome 152 alcanza el 80% de las cargas de página el 25 de agosto y que Chrome 154 lleva la desactivación predeterminada de unload al 100% de las cargas de página en el despliegue general el 22 de septiembre de 2026. La documentación también advierte que las versiones y las fechas pueden cambiar a medida que se evalúa el impacto.
Ese “100%” no significa que el evento haya sido eliminado de la plataforma ni que todos los usuarios se vean afectados a la vez. Significa que, en el despliegue general publicado por Chrome, el cambio predeterminado abarca el 100% de las cargas de página: los handlers de unload dejan de ejecutarse de forma predeterminada, salvo que el sitio utilice un mecanismo temporal de opt-in. La migración recomendada es abandonar la dependencia del evento, no convertir ese opt-in en una solución permanente. La referencia principal es la documentación de descontinuación de unload en Chrome.
Qué cambia en Chrome 154
Chrome comenzó en 2026 a ampliar la descontinuación a todos los orígenes. La tabla pública avanza por 1%, 5%, 10%, 20%, 40%, 60% y 80% hasta Chrome 152; la siguiente etapa publicada es Chrome 154, con 100% el 22 de septiembre. No existe una etapa de despliegue de Chrome 153 en la tabla actual.
En la práctica, el código que trata unload como un callback garantizado se vuelve más visiblemente frágil. Esto es especialmente riesgoso cuando el handler contiene una tarea que el producto considera obligatoria, como guardar el estado final de un formulario, marcar el final de una sesión o enviar un último lote de telemetría.
El problema no empezó con Chrome 154. El evento ya era poco fiable, sobre todo en dispositivos móviles, porque las páginas pueden pasar a segundo plano, congelarse o finalizar sin una secuencia clásica de “salida”. Además, los handlers de unload perjudican el uso del back/forward cache, o bfcache, que permite restaurar páginas rápidamente al navegar hacia atrás o hacia adelante.
Primer paso: encuentra todas las dependencias de unload
Empieza por el repositorio, pero no te detengas allí. Busca unload, onunload y registros equivalentes mediante addEventListener. Revisa código propio, bundles generados e integraciones de terceros que puedan registrar el evento en runtime.
- Clasifica cada aparición por función: persistencia, telemetría, limpieza de recursos, aviso al usuario o código legado sin efecto claro.
- Identifica si el handler realiza llamadas de red, escrituras en storage, cierre de conexiones o mutaciones globales.
- Revisa librerías de analytics, widgets y tags cargados fuera del bundle principal.
- Usa la prueba de Back/forward cache de Chrome DevTools para detectar listeners que vuelven la página inelegible para bfcache.
- En producción, la Reporting API y la propiedad notRestoredReasons pueden ayudar a localizar el uso de unload y los motivos por los que una página no se restauró desde bfcache.
No encontrar “unload” en el código fuente de la aplicación no demuestra que la página esté libre de él. Un script de terceros puede añadir el listener después de la carga, por eso la auditoría en runtime es importante.
Qué alternativa usar en cada caso
| Caso de uso | Sustitución principal | Cuidado de implementación |
|---|---|---|
| Guardar borradores o estado local | visibilitychange cuando el documento pasa a hidden, combinado con guardado incremental | No esperes un “evento final” para persistirlo todo; haz que la operación sea repetible y barata. |
| Enviar analytics o telemetría | visibilitychange + navigator.sendBeacon(); usa fetch con keepalive cuando necesites más control | Evita duplicados porque una página puede pasar a hidden más de una vez o ser restaurada. |
| Detectar navegación fuera de una página | pagehide | El evento también puede preceder la entrada en bfcache; no asumas la destrucción definitiva del documento. |
| Liberar y luego restaurar recursos | pagehide y pageshow | Si la página vuelve desde bfcache, reactiva lo que fue suspendido o limpiado. |
| Avisar sobre cambios no guardados | beforeunload, solo de forma condicional | Úsalo únicamente mientras existan cambios realmente no guardados; tampoco garantiza ejecución ante un cierre en segundo plano. |
Persistencia: guarda antes del punto de no retorno
Para formularios, editores y estado de interfaz, Chrome recomienda tratar la transición a hidden en visibilitychange como el último momento fiable para guardar datos de la aplicación y del usuario. Esto funciona mejor cuando el sistema ya realiza guardados incrementales durante la interacción, en lugar de concentrar toda la responsabilidad en el cierre de la página.
El objetivo es transformar “guardar al salir” en “mantener el estado suficientemente actualizado”. Así, si el proceso del navegador termina sin otro evento, la pérdida posible queda limitada al menor intervalo práctico.
Analytics: separa el final de sesión de la entrega fiable
Para cargas pequeñas de telemetría, navigator.sendBeacon() está diseñado para enviar datos de forma asíncrona sin bloquear la siguiente navegación. MDN recomienda activarlo cuando el documento pasa a hidden. Cuando una petición necesita un método distinto de POST, headers personalizados o más control, fetch con keepalive puede ser más apropiado. Consulta la referencia de sendBeacon.
No trates cada visibilitychange como el “fin definitivo de sesión”. El usuario puede cambiar de pestaña y volver. Usa identificadores de evento, checkpoints o deduplicación en el servidor para no inflar las métricas.
Limpieza: pagehide no significa destrucción definitiva
pagehide es adecuado para detectar que se está abandonando la página, pero es compatible con bfcache. Si la página entra en la caché de navegación, su estado puede restaurarse después. Por eso, cualquier limpieza que deje la aplicación incapaz de continuar necesita una etapa complementaria en pageshow. La Page Lifecycle API documenta los estados y eventos involucrados.
Cómo migrar sin cambiar un bug por otro
- Extrae la lógica del handler. Separa la tarea real del disparador “unload”. Una función de guardado, telemetría o suspensión de recursos debe poder llamarse desde otro evento.
- Haz la operación idempotente. visibilitychange puede ocurrir varias veces. Repetir una acción no debe duplicar peticiones, eventos de analytics ni escrituras incompatibles.
- Elige el evento por su significado. Usa visibilitychange para persistencia y telemetría de probable fin de sesión; pagehide para abandonar una página; pageshow para restauración; beforeunload solo para avisos de cambios no guardados.
- Gestiona la restauración desde bfcache. En pageshow, la propiedad persisted indica que la página fue restaurada desde la caché. Reevalúa los datos que deban actualizarse y los recursos que se hayan suspendido.
- Prueba con unload ya desactivado. No valides únicamente contra el comportamiento actual del navegador.
Cómo probar ahora, antes del 22 de septiembre
Chrome ofrece formas de adelantar el comportamiento futuro. La opción chrome://flags/#deprecate-unload, cuando se habilita como indica la documentación, adelanta el valor predeterminado de la descontinuación y permite probar la aplicación con handlers de unload que ya no se ejecutan. Permissions Policy también puede controlar el acceso al evento por página o sitio. Estos mecanismos sirven para pruebas y contingencia, no para mantener la dependencia indefinidamente.
Construye una matriz mínima de regresión:
- navegación interna y navegación a otro dominio;
- retroceder y avanzar en el historial;
- recargar la página;
- cerrar la pestaña;
- cambiar de pestaña, minimizar el navegador y, en móvil, cambiar de aplicación;
- restaurar una página desde bfcache;
- simular una conexión lenta u offline durante autosave y telemetría.
El objetivo no es demostrar que existe un nuevo “evento final garantizado”. El objetivo es mostrar que el sistema sigue siendo consistente incluso cuando la página no recibe ningún callback de cierre.
bfcache: la migración puede cambiar rendimiento y analytics
Eliminar listeners de unload puede hacer que más páginas sean elegibles para bfcache. Esto tiende a mejorar la navegación hacia atrás y hacia adelante, pero también cambia la forma en que se observa el ciclo de vida: una restauración desde bfcache recupera la página existente, incluido su heap de JavaScript, en vez de realizar una carga completa.
Para analytics, esto significa que una restauración puede no generar automáticamente el mismo pageview que una carga nueva. Chrome recomienda escuchar pageshow y comprobar event.persisted cuando el producto necesita contar restauraciones. Para los datos de la aplicación, decide si algún contenido debe revalidarse después de restaurar. Consulta también la guía de bfcache de web.dev.
beforeunload no es un sustituto general
beforeunload sigue existiendo porque resuelve un problema diferente: permite un aviso cancelable cuando el usuario intenta salir con cambios no guardados. No debe sustituir unload para analytics, persistencia o limpieza. La orientación de Chrome es añadirlo solo mientras haya cambios sin guardar y retirarlo en cuanto esos cambios se hayan persistido.
Tampoco está garantizado que se ejecute cuando una pestaña en segundo plano termina. Por eso, incluso en editores que usan beforeunload como red de seguridad de UX, el guardado real debe ocurrir antes.
Checklist para llegar a Chrome 154 sin depender de unload
- Ningún flujo crítico depende de un callback final de unload.
- Los borradores y el estado importante se guardan de forma incremental y en visibilitychange al pasar a hidden.
- La telemetría usa sendBeacon o fetch keepalive cuando corresponde e incluye deduplicación.
- La limpieza asociada a pagehide puede revertirse o reactivarse en pageshow.
- beforeunload existe solo mientras haya cambios realmente no guardados.
- El sitio fue probado con la descontinuación adelantada y con Back/forward cache en DevTools.
- Las restauraciones desde bfcache se tuvieron en cuenta en los datos y en analytics.
- Cualquier opt-in para mantener unload se trata como contingencia temporal, con un plan de retirada.
Con la etapa del 100% prevista para el 22 de septiembre de 2026, el mayor riesgo no es la desaparición de una API aislada: es descubrir demasiado tarde que una rutina de persistencia o telemetría dependía de un evento que nunca fue fiable. Una migración segura distribuye esas responsabilidades a lo largo del ciclo de vida de la página y prueba explícitamente navegación, segundo plano y restauración.
