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 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 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: 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 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 (memoria 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 para quienes inhabiliten explícitamente la baja.
¿Por qué 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: 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 cierra la ventana del navegador. El eventopagehideno se activa cuando simplemente se minimiza la página 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 cancelable. 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 información, consulta esta sugerencia sobre cómo no usar nunca 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 la página, abre Herramientas para desarrolladores y navega a Aplicación > Servicios en segundo plano > Memoria caché atrás/adelante.
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 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 muestra una lista de problemas. En Actionable, puedes ver si estás usando 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.
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, 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 la 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 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 esta opción en tu sitio. Esto les permite a los sitios anticiparse 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 a fin de evitar la baja gradual de los dispositivos que estén 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.
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. Se pueden anular por sitio a través de 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
En la siguiente tabla, se resumen los diferentes usos de las opciones que se analizaron anteriormente:
| Avanza la baja | Llevar la baja al futuro (con excepciones) | Evita la baja para asegurarte de tener tiempo para una migración | |
|---|---|---|---|
| Política de Permisos (se aplica a páginas y 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 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 se necesita 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