El evento unload dejará de estar disponible de forma gradual (obsoleto). Para ello, se cambiará gradualmente el valor predeterminado de modo que los controladores de unload dejen de activarse en las páginas, a menos que una página acepte explícitamente volver a habilitarlos.
Cronograma de baja
Notamos que el comportamiento de descarga probablemente estaría sujeto a cambios desde enero de 2019, cuando anunciamos nuestra intención de implementar una caché de atrás/adelante. En paralelo con el trabajo de implementación, realizamos una gran divulgación que generó una disminución significativa del uso de la descarga. Para complementar esta divulgación, también comenzamos a ofrecer formas de probar el efecto de dar de baja la descarga a partir de Chrome 115:
- Pruebas reales a través de la API de Permissions-Policy para la descarga en Chrome 115 (julio de 2023)
- Pruebas locales mediante la habilitación de una marca en Chrome 117 (septiembre de 2023)
Después de estas fases de divulgación y prueba, esperamos que la baja gradual se lance de la siguiente manera:
- Una fase centrada en la que la descarga dejará de funcionar gradualmente para los 50 sitios populares principales (referencia al momento de escribir este artículo).
- Comenzará con el 1% de los usuarios a partir de Chrome 120 (finales de noviembre de 2023).
- Finalizar con el 100% de los usuarios a fines del tercer trimestre de 2024
- Además, a partir del tercer trimestre de 2024, tenemos la intención de iniciar una fase genérica en la que la descarga dejará de funcionar gradualmente en todos los sitios, comenzando con el 1% de los usuarios y terminando con el 100% de los usuarios a fines del primer trimestre de 2025.
Ten en cuenta que también ofrecemos un menú de opciones de inhabilitación en caso de que este cronograma de baja gradual no proporcione tiempo suficiente para migrar de la descarga. Nuestro objetivo es usar esta baja no definitiva para informar el cronograma de la última fase (baja definitiva de la descarga) en la que se quitarán o reducirán estas inhabilitaciones.
Segundo plano
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 salga de una página o como devolución de llamada de fin de sesión.
Estas son algunas de las situaciones en las que se usó más este evento:
- 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 evento unload es muy poco confiable.
En Chrome y Firefox para computadoras, unload es bastante confiable, pero tiene un impacto negativo en el rendimiento de un sitio, ya que evita el uso de bfcache (caché de atrás/adelante).
En los navegadores para dispositivos móviles, unload suele no ejecutarse, ya que las pestañas se colocan con frecuencia en segundo plano y, luego, se cancelan. 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 de escritorio.
El equipo de Chrome cree que usar el modelo para dispositivos móviles de priorizar bfcache sobre unload en computadoras de escritorio sería disruptivo, ya que lo haría menos confiable allí también, cuando antes era bastante confiable en Chrome (y Firefox). En cambio, el objetivo de Chrome es quitar el evento unload por completo. Hasta entonces, seguirá siendo confiable en computadoras de escritorio para quienes inhabiliten explícitamente la baja.
¿Por qué se dará de baja el evento unload?
Dar de baja unload es un paso clave para un reconocimiento mucho más amplio de la Web en la que vivimos actualmente. El evento unload brinda una falsa sensación de control sobre el ciclo de vida de la app que es cada vez menos cierta de cómo navegamos por la Web en el mundo de la informática moderna.
Los sistemas operativos para dispositivos móviles suelen inhabilitar o descargar páginas web para conservar memoria, y los navegadores para computadoras de escritorio también lo hacen cada vez más por los mismos motivos. Incluso sin intervenciones del sistema operativo, los usuarios suelen cambiar de pestaña y cerrar pestañas antiguas sin “salir de las páginas” de forma formal.
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 dependa de conceptos desactualizados 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 el estadohiddencomo el último momento confiable para guardar datos de la app y del usuario.pagehide: Para determinar cuándo el usuario salió de la página. Este evento ocurre cuando el usuario sale de la página, la vuelve a cargar o cierra la ventana del navegador. El eventopagehideno se activa cuando la página simplemente se minimiza o se cambia a otra pestaña. Ten en cuenta que, comopagehideno hace que una página no sea apta para la memoria caché atrás/adelante, es posible que se pueda restablecer una página después de que se active este evento. Si limpias recursos en este evento, es posible que debas restablecerlos en el restablecimiento de la página.
El evento beforeunload tiene un caso de uso ligeramente diferente al de unload, ya que es un evento anulable. A menudo, se usa para advertir a los usuarios sobre los cambios no guardados cuando salen de una 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 solo agregarlo de forma condicional. En su lugar, usa los eventos anteriores para la mayoría de los reemplazos de unload.
Para obtener más detalles, consulta este consejo sobre por qué nunca debes usar el controlador unload.
Detecta el uso de unload
Existen diferentes herramientas para ayudarte a encontrar las apariciones del evento unload en las páginas. Esto permite que los sitios descubran si están usando este evento, ya sea en su propio código o a través de bibliotecas, y si pueden verse afectados por la próxima baja.
Herramientas para desarrolladores de Chrome
Herramientas para desarrolladores de Chrome incluye una auditoría de back-forward-cache para ayudarte a identificar problemas que podrían impedir que tu página sea apta para la caché de atrás/adelante, incluido el uso del controlador unload.
Para probar la caché de atrás/adelante, sigue estos pasos:
En tu página, abre DevTools y, luego, navega a Application > Background services > Back/forward cache.
Haz clic en Probar la caché de atrás/adelante. Chrome te llevará automáticamente a
chrome://terms/y volverá a tu página. También puedes hacer clic en los botones de atrás y adelante del navegador.
Si tu página no es apta para el almacenamiento en la memoria caché atrás/adelante, la pestaña Memoria caché atrás/adelante muestra una lista de problemas. En Acciones, puedes ver si usas unload:
API de informes
La API de Reporting se puede usar junto con una Política de Permisos de solo lectura para detectar el uso de unload por parte 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 notRestoredReasons de Bfcache
La propiedad notRestoredReasons, que se agregó a la clase PerformanceNavigationTiming, informa si se bloqueó a los documentos para que no usen bfcache en la navegación y por qué. Aquí encontrarás las instrucciones de uso. 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-handler"}
],
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 y prepararte para la próxima baja. Existen diferentes tipos de políticas:
- Política de Permisos: Esta es una API de plataforma para que los propietarios de sitios controlen el acceso a las funciones, a nivel de un sitio o de una página individual, mediante el uso de encabezados HTTP.
- Políticas de Enterprise: Son herramientas para que los administradores de TI configuren Chrome para su organización o empresa. Se pueden configurar a través de un panel de administración, como la Consola del administrador de Google.
- Marcas de Chrome: Permiten que un desarrollador individual cambie el parámetro de 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 esta opción en tu sitio. Esto permite que los sitios se anticipen a la baja de unload.
Esto se extenderá en Chrome 117 para permitir que los sitios hagan lo contrario y habiliten la opción de seguir intentando activar los controladores unload, ya que Chrome cambia el valor predeterminado para que no se activen en el futuro. Consulta estos ejemplos sobre cómo seguir permitiendo que se activen los controladores de descarga para tu sitio. Esta habilitación no permanecerá para siempre y se debe usar para permitir que los sitios migren de los controladores de unload.
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á estando habilitado de forma predeterminada para todos los orígenes. Una página 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 drásticos, pero no debe usarse de forma indefinida.
Marcas y parámetros de línea de comandos de Chrome
Además de la política empresarial, puedes inhabilitar la baja para usuarios individuales mediante las marcas de Chrome y los interruptores de línea de comandos:
Si configuras chrome://flags/#deprecate-unload en enabled, se adelantará la baja predeterminada y se evitará que se activen los controladores unload. Se pueden anular por sitio a través de la Política de Permisos, pero se seguirán activando de forma predeterminada.
Estos parámetros de configuración también se pueden controlar con interruptores de línea de comandos.
Comparación de opciones
En la siguiente tabla, se resumen los diferentes usos de las opciones que se analizaron anteriormente:
| Avanza la baja | Avanza la baja (con excepciones) | Evita la baja para asegurarte de tener 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 los dispositivos) |
No | No | Sí |
| Funciones experimentales de Chrome (se aplica a usuarios individuales) |
Sí | No | No |
| Interruptores de la línea de comandos de Chrome (se aplica a usuarios individuales) |
Sí | No | Sí |
Conclusión
Los controladores de 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 bfcache.
Los sitios que actualmente usan controladores unload deben prepararse para esta baja próxima. Para ello, deben probar si hay controladores unload existentes, quitarlos o migrarlos, o bien, como último recurso, retrasar la baja si necesitan más tiempo.
Agradecimientos
Gracias a Kenji Baheux, Fergal Daly, Adriana Jara y Jeremy Wagner por ayudar a revisar este artículo.
Imagen hero de Anja Bauermann en Unsplash