Mejora de la eliminación de páginas en XMLHttpRequest () sincrónico

Es común que una página o aplicación tenga análisis u otros datos sin enviar en el momento en que un usuario la cierra. Para evitar la pérdida de datos, algunos sitios utilizan una llamada sincrónica para XMLHttpRequest() para mantener la página o aplicación abierta hasta que sus datos se pasen al servidor. No solo existen mejores formas de guardar datos, sino que esta técnica crea una mala experiencia de usuario al retrasar el cierre de la página hasta varios segundos.

Esta práctica debe cambiar y los navegadores están respondiendo. los XMLHttpRequest()
la especificación ya está programado para su desaprobación y eliminación. Chrome 80 da el primer paso al no permitir llamadas síncronas dentro de varios controladores de eventos, específicamente beforeunload, unload, pagehidey visibilitychange cuando son despedidos en el despido. WebKit también aterrizó recientemente un compromiso que implementa el mismo cambio de comportamiento.

En este artículo, describiré brevemente las opciones para aquellos que necesitan tiempo para actualizar sus sitios y describiré las alternativas para XMLHttpRequest().

Exclusiones temporales

Chrome no solo quiere desconectar XMLHttpRequest(), razón por la cual están disponibles algunas opciones de exclusión voluntaria. Para sitios en Internet, una prueba de origen está disponible. Con esto, agrega un token específico de origen a los encabezados de su página que habilita la sincronización XMLHttpRequest() llamadas. Esta opción finaliza poco antes del lanzamiento de Chrome 89, en algún momento de marzo de 2021. Los clientes de Enterprise Chrome también pueden usar AllowSyncXHRInPageDismissal bandera de política, que finaliza al mismo tiempo.

Alternativas

Independientemente de cómo envíe los datos al servidor, es mejor evitar esperar hasta que se descargue la página para enviar todos los datos a la vez. Además de crear una mala experiencia de usuario, corre el riesgo de perder datos si algo sale mal. Descargar eventos a menudo no se activa en navegadores móviles
porque hay muchas formas de cerrar una pestaña o navegador en sistemas operativos móviles sin la unload evento de disparo. Con
XMLHttpRequest(), usar pequeñas cargas útiles fue una elección. Ahora es un requisito. Ambas alternativas tienen un límite de carga de 64 KB por contexto, como lo requiere la especificación.

Obtener keepalive

los Obtener API
proporciona un medio sólido para tratar las interacciones con el servidor y una interfaz consistente para su uso en diferentes API de plataforma. Entre sus opciones esta keepalive, lo que garantiza que una solicitud continúe independientemente de que la página que la realizó permanece abierta o no:

window.addEventListener('unload', {
  fetch('/siteAnalytics', {
    method: 'POST',
    body: getStatistics(),
    keepalive: true
  });
}

los fetch() El método tiene la ventaja de un mayor control sobre lo que se envía al servidor. Lo que no muestro en el ejemplo es que fetch() también devuelve una promesa que se resuelve con un Response objeto. Como estoy tratando de evitar la descarga de la página, elegí no hacer nada con ella.

EnviarBeacon ()

SendBeacon()

en realidad usa la API Fetch bajo el capó, razón por la cual tiene la misma limitación de carga útil de 64 KB y por qué también asegura que una solicitud continúe después de la descarga de una página. Su principal ventaja es su sencillez. Le permite enviar sus datos con una sola línea de código:

window.addEventListener('unload', {
navigator.sendBeacon('/siteAnalytics', getStatistics());
}

Conclusión

Con el mayor disponibilidad de
fetch()

en los navegadores, XMLHttpRequest() Con suerte, se eliminará de la plataforma web en algún momento. Los proveedores de navegadores están de acuerdo en que debería eliminarse, pero llevará tiempo. Dejar de lado uno de sus peores casos de uso es un primer paso que mejora la experiencia del usuario para todos.

Foto por Matthew Hamilton en Unsplash