Fecha de publicación: 10 de agosto de 2023; última actualización: 28 de abril de 2026
El evento unload dejará de estar disponible de forma gradual. Para ello, se cambiará el valor predeterminado de manera progresiva para que los controladores unload dejen de activarse en las páginas, a menos que una página acepte explícitamente volver a habilitarlos.
Cronograma de baja
Observamos que el comportamiento de descarga probablemente estaría sujeto a cambios a partir de enero de 2019, cuando anunciamos nuestra intención de implementar una memoria caché atrás/adelante. Paralelamente al trabajo de implementación, realizamos una gran divulgación que provocó una disminución significativa del uso de la descarga. Para complementar esta comunicación, también comenzamos a ofrecer formas de probar el efecto de dejar de estar disponible la descarga a partir de Chrome 115:
- Pruebas en el entorno real con la API de Permission-Policy para la descarga en Chrome 115 (julio de 2023)
- Pruebas locales habilitando una marca en Chrome 117 (septiembre de 2023)
A lo largo de 2024, abordamos varios problemas que impedían el inicio del lanzamiento y, durante 2025, lanzamos la baja a los 50 sitios principales.
| Meta | Fecha de la meta | 50 sitios principales | % de otros orígenes |
|---|---|---|---|
| 135 | 26 de marzo de 2025 | 1 (www.google.com) |
0 |
| 139 | 30 de julio de 2025 | 5 | 0 |
| 140 | 27 de agosto de 2025 | 10 | 0 |
| 141 | 24 de septiembre de 2025 | 25 | 0 |
| 142 | 22 de octubre de 2025 | 50 | 0 |
Ahora que completamos la baja de los 50 sitios principales, obtuvimos más aprobación para lanzarla a todos los orígenes en más de 8 metas (o aproximadamente 32 semanas), como se detalla en la siguiente tabla.
| Meta | Fecha de la meta | 50 sitios principales | % de cargas de páginas de Chrome para todos los sitios |
|---|---|---|---|
| 146 | 10 de marzo de 2026 | 50 | 1 |
| 147 | 7 de abril de 2026 | 50 | 5 |
| 148 | 5 de mayo de 2026 | 50 | 10 |
| 149 | 2 de junio de 2026 | 50 | 20 |
| 150 | 30 de junio de 2026 | 50 | 40 |
| 151 | 28 de julio de 2026 | 50 | 60 |
| 152 | 25 de agosto de 2026 | 50 | 80 |
| 153 | 22 de septiembre de 2026 | 50 | 100 |
El lanzamiento completo se basa en las cargas de páginas (con coherencia a lo largo del tiempo), en lugar de usuarios o sitios individuales para evitar que los usuarios o sitios se vean afectados más que otros, como se detalla en la intención de baja.
Ten en cuenta que también ofrecemos un menú de opciones de inhabilitación en caso de que este cronograma de baja no proporcione suficiente tiempo para migrar de la descarga. Nuestro objetivo es usar esta baja gradual para informar el cronograma de la última fase (baja definitiva de la descarga), en la que se quitarán o reducirán estas inhabilitaciones.
Fondo
unload se diseñó para activarse cuando se descarga el documento. En teoría, se puede usar para ejecutar código cada vez que un usuario abandona una página o como una devolución de llamada al final de la sesión.
Entre las situaciones en las que se usaba con mayor frecuencia este evento, se incluyen las siguientes:
- Guardar datos del usuario: Guarda los datos antes de salir de la página.
- Realizar tareas de limpieza: Cierra los recursos abiertos antes de abandonar la página.
- Enviar estadísticas: Envía datos relacionados con las interacciones del usuario al final de la sesión.
Sin embargo, el unload evento no es confiable.
En Chrome y Firefox para computadoras, unload es razonablemente confiable, pero tiene un impacto negativo en el rendimiento de un sitio, ya que impide el uso de la bfcache (memoria caché atrás/adelante).
En los navegadores para dispositivos móviles, unload a menudo no se ejecuta, ya que las pestañas suelen estar en segundo plano y, luego, se cierran. Por este motivo, los navegadores eligen priorizar la bfcache en dispositivos móviles sobre unload, lo que los hace aún menos confiables. Safari también usa este comportamiento en computadoras.
El equipo de Chrome cree que usar el modelo móvil de priorizar la bfcache sobre unload en computadoras sería perjudicial, ya que también lo haría menos confiable, cuando antes era razonablemente confiable en Chrome (y Firefox). En cambio, el objetivo de Chrome es quitar por completo el evento unload. Hasta entonces, seguirá siendo confiable en computadoras para quienes hayan inhabilitado explícitamente la baja.
¿Por qué dar de baja el evento unload?
La baja de unload es un paso clave en un reconocimiento mucho más grande de la Web en la que vivimos ahora. El evento unload da una falsa sensación de control del ciclo de vida de la app que es cada vez más falsa sobre cómo navegamos por la Web en el mundo moderno de la informática.
Los sistemas operativos para dispositivos móviles suelen congelar o descargar páginas web para conservar la memoria, y los navegadores para computadoras también lo hacen cada vez más por los mismos motivos. Incluso sin las intervenciones del sistema operativo, los usuarios suelen cambiar de pestaña y cerrar las pestañas antiguas sin "abandonar las páginas" formalmente.
Quitar el evento unload como obsoleto es un reconocimiento de que, como desarrolladores web, debemos asegurarnos de que nuestro paradigma coincida con el del mundo real y no depender de conceptos obsoletos que ya no son válidos, si es que alguna vez lo fueron.
Alternativas a los eventos unload
En lugar de unload, se recomienda usar lo siguiente:
visibilitychange: Para determinar cuándo cambia la visibilidad de una página. Este evento ocurre cuando el usuario cambia de pestaña, minimiza la ventana del navegador o abre una página nueva. Considera elhiddenestado como el último momento confiable para guardar datos de la app y del usuario.pagehide: Para determinar cuándo el usuario abandonó la página. Este evento ocurre cuando el usuario abandona la página, la vuelve a cargar o cierra la ventana del navegador. El eventopagehideno se activa cuando la página se minimiza o se cambia a otra pestaña. Ten en cuenta que, comopagehideno inhabilita una página para la memoria caché atrás/adelante, es posible que se pueda restablecer después de que se active este evento. Si limpias algún recurso en este evento, es posible que debas restablecerlo en la página.
El evento beforeunload tiene un caso de uso ligeramente diferente a unload ya que es un evento cancelable. A menudo, se usa para advertir a los usuarios sobre los cambios no guardados cuando abandonan la página. Este evento tampoco es confiable, ya que no se activará si se cierra una pestaña en segundo plano. Se recomienda limitar el uso de beforeunload y agregarlo solo de forma condicional. En su lugar, usa los eventos mencionados anteriormente para la mayoría de los reemplazos de unload.
Para obtener más detalles, consulta este consejo sobre nunca usar el controlador unload.
Detecta el uso de unload
Existen diferentes herramientas que te ayudan a encontrar las apariciones del evento unload en las páginas. Esto permite que los sitios descubran si usan este evento, ya sea en su propio código o con bibliotecas, y, por lo tanto, pueden verse afectados por la próxima baja.
Herramientas para desarrolladores de Chrome
Las Herramientas para desarrolladores de Chrome incluyen una back-forward-cache auditoría para ayudarte a identificar problemas que pueden impedir que tu página sea apta para la memoria caché atrás/adelante, incluido el uso del controlador unload.
Para probar la memoria caché atrás/adelante, sigue estos pasos:
En tu página, abre las Herramientas para desarrolladores y, luego, navega a Application > Background services > Memoria caché atrás/adelante.
Haz clic en Test back/forward cache . Chrome te llevará automáticamente a
chrome://terms/y volverá a tu página. Como alternativa, puedes hacer clic en los botones Atrás y Adelante del navegador.
Si tu página no es apta para el almacenamiento en caché atrás/adelante, la pestaña Back/forward cache te mostrará una lista de problemas. En Actionable, puedes ver si usas unload:
API de Reporting
La API de Reporting se puede usar junto con una política de permisos de solo lectura para detectar el uso de unload de los usuarios de tu sitio web.
Para obtener más detalles, consulta Cómo usar la API de Reporting para encontrar descargas
API de Bfcache notRestoredReasons
La propiedad notRestoredReasons—que se agregó a la clase PerformanceNavigationTiming—informa si se impidió que los documentos usaran la bfcache en la navegación y por qué. Este es un ejemplo de cómo se ve la advertencia del objeto de respuesta de un objeto de escucha unload existente:
{
children: [],
id: null,
name: null,
reasons: [
{"reason", "unload-listener"}
],
src: null,
url: "https://www.example.com/page/"
}
Controla el acceso a unload
Chrome dará de baja el evento unload de forma gradual. Mientras tanto, puedes usar diferentes herramientas para controlar este comportamiento y prepararte para la próxima baja. Ten en cuenta que no debes depender de estas técnicas a largo plazo y que debes planificar la migración a las alternativas lo antes posible.
Las siguientes opciones te permiten habilitar o inhabilitar los controladores unload para probar cómo funcionaría tu sitio sin ellos, de modo que puedas prepararte para la próxima baja. Existen diferentes tipos de políticas:
- Política de permisos: Es una API de plataforma para que los propietarios de sitios controlen el acceso a las funciones, a nivel de sitio o de página individual, mediante encabezados HTTP.
- Políticas empresariales: Son herramientas para que los administradores de TI configuren Chrome para su organización o empresa. Se pueden configurar con un panel de administrador, como la Consola del administrador de Google.
- Funciones experimentales de Chrome: Esto permite que un desarrollador individual cambie la configuración de baja de
unloadpara probar el impacto en varios sitios.
Política de permisos
Se agregó una política de permisos a partir de Chrome 115 para permitir que los sitios inhabiliten el uso de controladores unload y se beneficien de inmediato de la bfcache para mejorar el rendimiento del sitio. Consulta estos ejemplos para configurar esto en tu sitio. Esto permite que los sitios se adelanten a la baja de unload.
Esto se extendió en Chrome 117 para permitir que los sitios hagan lo contrario y acepten seguir intentando activar los controladores unload como lo hacen ahora, ya que Chrome cambia el valor predeterminado para que no se activen en el futuro. Consulta estos ejemplos para seguir permitiendo que se activen los controladores de descarga en tu sitio. Si bien recomendamos a los propietarios de sitios que dejen de usar controladores unload debido a su falta de confiabilidad, planeamos admitir esta inhabilitación en el futuro considerable para los sitios que necesiten usarla. Además, volver a habilitar no hace que los controladores unload sean más confiables en dispositivos móviles, solo restablece el statu quo actual.
Política empresarial
Las empresas que tienen software que depende del evento unload para funcionar correctamente pueden usar la política ForcePermissionPolicyUnloadDefaultEnabled para evitar la baja gradual de los dispositivos bajo su control. Si habilitas esta política, unload seguirá siendo el valor predeterminado para todos los orígenes. Una página aún puede establecer una política más estricta si lo desea. Al igual que la inhabilitación de la política de permisos, esta es una herramienta para mitigar posibles cambios rotundos. Una vez más, recomendamos a los propietarios de sitios que dejen de depender de los controladores unload, pero Chrome planea admitir esta inhabilitación empresarial en el futuro considerable para los sitios que necesiten usarla.
Funciones experimentales de Chrome y modificadores de la línea de comandos
Además de la política empresarial, puedes inhabilitar la baja para usuarios individuales con las funciones experimentales de Chrome y los modificadores de la línea de comandos:
Si configuras chrome://flags/#deprecate-unload como enabled, se adelantará el valor predeterminado de baja y se evitará que se activen los controladores unload. Aún se pueden anular sitio por sitio con la política de permisos, pero seguirán activándose de forma predeterminada.
Estos parámetros de configuración también se pueden controlar con modificadores de la línea de comandos.
Comparación de opciones
En la siguiente tabla, se resumen los diferentes usos de las opciones analizadas anteriormente:
| Adelantar la baja | Adelantar la baja (con excepciones) | Evitar la baja para asegurar tiempo para una migración | |
|---|---|---|---|
| Política de permisos (se aplica a páginas o sitios) |
Sí | Sí | Sí |
| Política empresarial (se aplica a dispositivos) |
No | No | Sí |
| Funciones experimentales de Chrome (se aplica a usuarios individuales) |
Sí | No | No |
| Modificadores de la línea de comandos de Chrome (se aplica a usuarios individuales) |
Sí | No | Sí |
Conclusión
Los controladores unload dejarán de estar disponibles. No son confiables desde hace mucho tiempo y no se garantiza que se activen en todos los casos en los que se destruye un documento. Además, los controladores unload no son compatibles con la bfcache.
Los sitios que usan controladores unload deben prepararse para esta próxima baja probando los controladores unload existentes, quitándolos o migrándolos o, como último recurso, retrasando la baja si se necesita más tiempo.
Agradecimientos
Gracias a Kenji Baheux, Fergal Daly, Adriana Jara y Jeremy Wagner por su ayuda para revisar este artículo.
Imagen hero de Anja Bauermann en Unsplash