Da de baja el evento de descarga

Demián Renzulli

Barry Pollard

El evento unload se obsoleto de forma gradual si se cambia la configuración predeterminada 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 habilitarlos.

Cronograma de baja

Notamos que es probable que el comportamiento de descarga esté 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 un gran acercamiento que dio como resultado una disminución significativa del uso de descargas. Para complementar este alcance, también comenzamos a ofrecer formas de probar el efecto de dar de baja la descarga en Chrome 115:

• En pruebas de funcionamiento a través de la API de Permission-Policy para descargas 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 comunicación y prueba, esperamos que se lance la baja leve de la siguiente manera:

• Se trata de una fase con alcance en la que la descarga dejará de funcionar gradualmente para los 50 sitios populares más populares (referencia al momento de la redacción).
  • Comenzando con el 1% de los usuarios de Chrome 120 (a fines de noviembre de 2023).
  • Finalizar con el 100% de los usuarios a 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, gradualmente, la descarga dejará de funcionar en cualquier sitio, comenzando con el 1% de los usuarios y finalizando 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 no sea suficiente para migrar de la descarga. Nuestro objetivo es usar esta baja parcial para informar el cronograma de la última fase (baja definitiva de la descarga), 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 salga de una página o como una devolución de llamada de fin de sesión.

Las situaciones en las que este evento se utilizó con mayor frecuencia incluyen:

• Almacenamiento de datos del usuario: Guarda datos antes de salir de la página.
• Realizar tareas de limpieza: Cierre de los recursos abiertos antes de abandonar la página.
• Envío de estadísticas: Envío de datos relacionados con las interacciones de los usuarios al final de la sesión.

Sin embargo, el evento unload es muy poco confiable.

En la versión de Chrome y Firefox para computadoras de escritorio, unload es bastante 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 los navegadores para dispositivos móviles, unload a menudo no se ejecuta, ya que las pestañas suelen pasar a segundo plano y, luego, cerrarse. Por este motivo, los navegadores eligen priorizar la bfcache en dispositivos móviles por sobre unload, lo que las hace 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 para dispositivos móviles de priorizar la bfcache en comparación con unload en computadoras de escritorio sería molesto, ya que también sería más poco confiable allí, cuando anteriormente 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 las computadoras de escritorio para quienes hayan inhabilitado explícitamente la baja.

¿Por qué dar de baja el evento unload?

Dar de baja unload es un paso clave para lograr un reconocimiento 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 incierta de la forma en que navegamos por la Web en el mundo de la computación moderna.

Los sistemas operativos para dispositivos móviles con frecuencia congelan o descargan páginas web para conservar la memoria, y los navegadores de escritorio lo están haciendo cada vez más por las mismas razones. Incluso sin la intervención del sistema operativo, los usuarios con frecuencia cambian de pestaña y cierran pestañas antiguas sin "abandonar páginas" formalmente.

Quitar el evento unload como obsoleto es un reconocimiento que nosotros, como desarrolladores web, necesitamos garantizar que nuestro paradigma coincida con el del mundo real y no depender de conceptos desactualizados que ya no son verdaderos, si es que alguna vez lo hicieron.

Alternativas a los eventos de 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. Considera el estado hidden como 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, vuelve a cargarla o cierra la ventana del navegador. El evento pagehide no se activa cuando simplemente se minimiza la página o se cambia a otra pestaña. Ten en cuenta que, como pagehide no determina que una página no sea apta para la memoria caché atrás/adelante, es posible restablecerla después de que se active este evento. Si estás borrando recursos en este evento, es posible que debas restablecerlos durante el restablecimiento de la página.

El evento beforeunload tiene un caso de uso ligeramente diferente al de unload, ya que es un evento cancelable. A menudo, se usa para advertir a los usuarios sobre los cambios no guardados cuando salen de 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 anteriores para la mayoría de los reemplazos de unload.

Para obtener más información, consulta esta sugerencia sobre cómo no usar nunca el controlador unload.

Detectar el uso de unload

Hay diferentes herramientas para ayudarte a encontrar 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 mediante bibliotecas, y, por lo tanto, es posible que se vean afectados por la baja futura.

Herramientas para desarrolladores de Chrome

Las herramientas para desarrolladores de Chrome incluyen una auditoría de back-forward-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:

1. En tu página, abre Herramientas para desarrolladores y, luego, navega a Aplicación > Servicios en segundo plano > Memoria caché atrás/adelante.

2. Haz clic en Probar la memoria caché atrás/adelante. Chrome te lleva automáticamente a chrome://terms/ y de vuelta a tu página. También puedes hacer clic en los botones para retroceder y adelantar 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 te mostrará una lista de problemas. En Actionable, puedes ver si estás usando unload:

API de informes

Puedes 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.

Si deseas 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, brinda información sobre si se bloqueó el uso de bfcache en la navegación en los documentos 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 gradualmente. Mientras tanto, puedes usar diferentes herramientas para controlar este comportamiento y prepararte para la próxima baja. Ten en cuenta que no debes confiar en estas técnicas a largo plazo y 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 la plataforma para que los propietarios de sitios controlen el acceso a las funciones, a nivel de sitio o de página individual, mediante el uso de encabezados HTTP.
• Políticas empresariales: Herramientas para que los administradores de TI configuren Chrome para su organización o negocio. Se pueden configurar en 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 la baja de unload para 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 del sitio. Consulta estos ejemplos para configurar esta opción en tu sitio. Esto les permite a los sitios anticiparse a la baja de unload.

Esta se extenderá en Chrome 117 para permitir que los sitios realicen lo contrario y acepten seguir intentando activar controladores unload, ya que Chrome cambia la configuración predeterminada para que no se activen en el futuro. Consulta estos ejemplos sobre cómo seguir permitiendo que los controladores de descarga se activen en tu sitio. Esta habilitación no se mantendrá para siempre y debe usarse para que los sitios tengan tiempo de migrarse de los controladores unload.

Política empresarial

Las empresas que tienen software que depende del evento unload para funcionar correctamente pueden usar la política ForcePermissionPolicyUnloadDefaultEnabled a fin de evitar la baja gradual de los dispositivos que estén bajo su control. Si habilitas esta política, unload seguirá habilitado de forma predeterminada para todos los orígenes. Aun así, una página puede establecer 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 se debe usar de forma indefinida.

Funciones experimentales de Chrome e interruptores de línea de comandos

Además de la política empresarial, puedes inhabilitar la baja para los usuarios individuales mediante los interruptores de líneas de comandos y funciones experimentales de Chrome:

Si estableces chrome://flags/#deprecate-unload como enabled, se avanzará el valor predeterminado de baja y se impedirá que se activen los controladores unload. Aun así, podrán anularse sitio por sitio a través de la Política de Permisos, pero seguirán activándose de forma predeterminada.

Esta configuración también se puede 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:

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 destruye un documento. Además, los controladores unload no son compatibles con bfcache.

Los sitios que actualmente utilizan controladores unload deben prepararse para esta próxima 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 ayudarnos con la revisión de este artículo.

Hero image de Anja Bauermann en Unsplash