El evento unload dejará de estar disponible de manera gradual. Para ello, se cambiará la configuración predeterminada de forma gradual para que los controladores unload dejen de activarse en las páginas, a menos que una página habilite explícitamente la opción para volver a habilitarlas.
Cronograma de baja
Notamos que el comportamiento de descarga podría estar sujeto a cambios a partir de enero de 2019, cuando anunciamos nuestra intención de implementar una memoria caché atrás/adelante. En paralelo al trabajo de implementación, realizamos un gran alcance, lo que generó una disminución significativa en el uso de descargas. Para complementar este alcance, también comenzamos a ofrecer formas de probar el efecto de dar de baja las descargas de Chrome 115:
- En pruebas reales a través de la API de Authorization-Policy para descargas en Chrome 115 (julio de 2023)
- Pruebas locales a través de la habilitación de una marca en Chrome 117 (septiembre de 2023)
Después de estas fases de comunicación y prueba, esperamos que se lance la baja no definitiva de la siguiente manera:
- Fase de alcance determinada en la que, gradualmente, la descarga dejará de funcionar para los 50 sitios populares más populares (referencia hasta el momento en que se escribió este documento).
- Comienza con el 1% de los usuarios de Chrome 120 (a fines de noviembre de 2023).
- Terminar con el 100% de los usuarios para fines del 3er trim. 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 gradualmente dejará de funcionar en cualquier sitio, comenzando con el 1% de los usuarios y finalizando con el 100% de los usuarios a fines del 1er trim. de 2025.
Ten en cuenta que también ofrecemos un menú de opciones para no participar en caso de que este cronograma de baja no definitiva no brinde el tiempo suficiente para migrar de la descarga. Nuestro objetivo es usar esta baja no definitiva para informar el cronograma de la última fase (baja de la descarga de forma definitiva), en la que se quitarán o reducirán estos rechazos.
Información general
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 sale de una página o como una devolución de llamada de fin de sesión.
Los escenarios en los que este evento se utilizó con mayor frecuencia incluyen los siguientes:
- Guardar datos del usuario: Guarda datos antes de abandonar la página.
- Realizar tareas de limpieza: Cerrar los recursos abiertos antes de abandonar la página.
- Envío de estadísticas: Envío de datos relacionados con las interacciones del usuario al final de la sesión.
Sin embargo, el evento unload es extremadamente poco confiable.
En Chrome y Firefox para computadoras de escritorio, unload es razonablemente confiable, pero tiene un impacto negativo en el rendimiento de un sitio, ya que evita el uso de bfcache (memoria caché atrás/adelante).
En navegadores para dispositivos móviles, unload no suele ejecutarse, ya que las pestañas pasan a segundo plano y, luego, se cierran. Por esta razón, los navegadores optan por priorizar la bfcache en dispositivos móviles por sobre unload, lo que hace que sean aún más poco confiables. Safari también usa este comportamiento en computadoras de escritorio.
El equipo de Chrome cree que usar el modelo móvil de priorizar la bfcache en lugar de unload en computadoras de escritorio podría ser perjudicial, ya que haría que ese modelo también fuera más poco confiable, cuando antes era razonablemente 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 hayan rechazado explícitamente esta opción.
¿Por qué dar de baja el evento unload?
La baja de unload es un paso clave en un reconocimiento mucho mayor de la Web en la que vivimos ahora. El evento unload brinda una falsa sensación de control del ciclo de vida de la app que es cada vez más real con respecto a la forma en que navegamos por la Web en el mundo informático moderno.
Con frecuencia, los sistemas operativos de dispositivos móviles se congelan o descargan páginas web para conservar la memoria, y los navegadores de escritorio lo hacen cada vez más por las mismas razones. Incluso sin intervenciones del sistema operativo, los mismos usuarios con frecuencia cambian de tabulación y cierran pestañas antiguas sin "abandonar páginas" formalmente.
Quitar el evento unload como obsoleto es un reconocimiento que nosotros, como desarrolladores web, debemos asegurarnos de que nuestro paradigma coincida con el del mundo real y no depender de conceptos desactualizados que ya no sean válidos, si es que lo hicieron alguna vez.
Alternativas a los eventos unload
En lugar de unload, se recomienda usar lo siguiente:
visibilitychange: Permite 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. Ten en cuenta el estadohidden, el último momento confiable para guardar datos de la app y del usuario.pagehide: Permite 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 cuando cierra la ventana del navegador. El eventopagehideno se activa cuando la página simplemente se minimiza o cambia a otra pestaña. Ten en cuenta que, comopagehideno hace que una página no sea apta para el almacenamiento en la memoria caché atrás/adelante, es posible que se pueda restablecer una página después de que se active este evento. Si, en este caso, estás limpiando algún recurso, es posible que deban restablecerse cuando se restablezca la página.
El evento beforeunload tiene un caso de uso ligeramente diferente del de unload, ya que se trata de un evento cancelable. A menudo, se usa para advertir a los usuarios sobre los cambios no guardados cuando salen de ella. Tampoco es posible realizar este evento, 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 información, consulta este consejo sobre cómo no usar nunca el controlador unload.
Detecta el uso de unload
Existen diferentes herramientas que te ayudarán a encontrar las apariciones del evento unload en las páginas. De esta manera, los sitios pueden descubrir si están usando este evento, ya sea en su propio código o a través de bibliotecas, y, por lo tanto, podría verse afectado por la baja.
Faro
Lighthouse tiene una auditoría de no-unload-listeners, que advierte a los desarrolladores si algún JavaScript en sus páginas (incluido el de bibliotecas de terceros) agrega un objeto de escucha de eventos unload.
Herramientas para desarrolladores de Chrome
Las herramientas para desarrolladores de Chrome incluyen una auditoría de back-foward-cache para ayudarte a identificar problemas que podrían impedir que tu página sea apta para el almacenamiento en la memoria caché atrás/adelante, incluido el uso del controlador unload.
Para probar la memoria caché atrás/adelante, sigue estos pasos:
En la página, abre Herramientas para desarrolladores, luego navega a Aplicación > Servicios en segundo plano > Memoria caché atrás/adelante.
Haz clic en Probar la memoria caché atrás/adelante Chrome te llevará automáticamente a
chrome://terms/y de vuelta a tu página. También puedes hacer clic en los botones Atrás y Avanzar 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 Practicidad, puedes ver si usas unload:
API de informes
Se puede usar la API de Reporting 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, agregada a la clase PerformanceNavigationTiming, informa información sobre si se bloqueó el uso de bfcache en la navegación y por qué los documentos. Puedes encontrar las instrucciones de uso aquí. Este es un ejemplo de cómo luce la advertencia de objeto de respuesta de un objeto de escucha unload existente:
{
blocked: true,
children: [],
id: "",
name: "",
reasons: [ "Internal Error", "Unload handler" ],
src: "",
url: "a.com"
}
Controla el acceso a unload
Chrome dará de baja el evento unload gradualmente. Mientras tanto, puedes usar diferentes herramientas para controlar este comportamiento y prepararte para la baja. Ten en cuenta que no debes confiar en estas técnicas a largo plazo y que, en cambio, deberías planificar migrar 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: Esta es una API de la plataforma para que los propietarios de sitios controlen el acceso a funciones, a nivel del sitio o de una página individual, mediante el uso de encabezados HTTP.
- Políticas empresariales: Son herramientas para que los administradores de TI configuren Chrome en su organización o empresa. Se pueden configurar desde un panel de administración, como la Consola del administrador de Google.
- Marcas de Chrome: Permiten a un desarrollador individual cambiar la configuración de baja de
unloadpara probar el impacto en varios sitios.
Política de Permisos
Se agregó una política de permisos desde 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 de los sitios. Consulta estos ejemplos para configurar esta función para tu sitio. Esto permite que los sitios se anticipen a la baja de unload.
Esta función se extenderá en Chrome 117 para permitir que los sitios realicen la acción inversa y acepte seguir intentando activar los controladores de unload, ya que Chrome cambia la configuración predeterminada para que no se activen en el futuro. Consulta estos ejemplos para seguir permitiendo que los controladores de descarga se activen en tu sitio. Esta aceptación no permanecerá para siempre y se debe usar para dar tiempo a que los sitios migren fuera 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 que controlan. Si habilitas esta política, la configuración unload seguirá habilitada de forma predeterminada para todos los orígenes. Es posible que una página establezca una política más estricta si así lo desea. Al igual que la inhabilitación de la Política de Permisos, esta es una herramienta para mitigar posibles cambios rotundos, pero no debe usarse de forma indefinida.
Interruptores de línea de comandos y marcas de Chrome
Además de la política empresarial, puedes inhabilitar la baja para usuarios individuales mediante los cambios de marcas y líneas de comandos de Chrome:
Si estableces chrome://flags/#deprecate-unload como enabled, se enviará el valor predeterminado de baja y se impedirá que se activen los controladores unload. Pueden anularse en cada sitio mediante la Política de Permisos, pero se seguirán activando de forma predeterminada.
Esta configuración también se puede controlar con interruptores de línea de comandos.
Comparación de opciones
La siguiente tabla resume los diferentes usos de las opciones analizadas anteriormente:
| Avanzar la baja | Baja del nivel de servicio (con excepciones) | Evita la baja a fin de asegurar un momento para una migración | |
|---|---|---|---|
| Política de Permisos (se aplica a las páginas y los sitios) |
Sí | Sí | Sí |
| Política empresarial (se aplica a los dispositivos) |
No | No | Sí |
| Funciones experimentales de Chrome (se aplican 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 unload dejarán de estar disponibles. No han sido confiables por mucho tiempo y no se garantiza que se activen en todos los casos en los que se destruya un documento. Además, los controladores unload no son compatibles con bfcache.
Los sitios que actualmente usan controladores unload deben prepararse para esta baja. Para ello, deben probar los controladores unload existentes, quitarlos o migrarlos, o bien, como último recurso, retrasar 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.
Hero image de Anja Bauermann en Unsplash