Reduce delayed navigations
Updated
It's common for a page or app to have unsent analytics or other data the moment a user closes it. To avoid data loss, some sites use a synchronous call to XMLHttpRequest () to keep the page or application open until your data is passed to the server. Not only are there better ways to save data, but this technique creates a bad user experience by delaying the closing of the page for up to several seconds.
This practice needs to change and browsers are responding. the XMLHttpRequest ()
the specification is already scheduled for disapproval and removal. Chrome 80 takes the first step by not allowing synchronous calls within various event handlers, specifically beforeunload, unload, pagehideand visibilitychange when they are fired on layoff. WebKit also recently landed a commitment that implements the same behavior change.
In this article, I will briefly describe the options for those who need time to update their sites and describe the alternatives for XMLHttpRequest ().
Temporary exclusions
Chrome doesn't just want to disconnect XMLHttpRequest (), which is why some opt-out options are available. For sites on the Internet, a proof of origin is available. With this you add a source specific token to your page headers which enables syncing XMLHttpRequest () calls. This option ends shortly before the launch of Chrome 89, sometime in March 2021. Enterprise Chrome customers can also use AllowSyncXHRInPageDismissal policy flag, which ends at the same time.
Alternatives
Regardless of how you send the data to the server, it is best to avoid waiting for the page to download to send all the data at once. In addition to creating a bad user experience, you risk losing data if something goes wrong. Download events often not activated on mobile browsers
because there many ways to close a tab or browser on mobile operating systems without the unload trigger event. With
XMLHttpRequest (), using small payloads was a choice. Now it is a requirement. Both alternatives have a 64 KB upload limit per context, as required by the spec.
Get keepalive
the Get API
provides a robust means of handling interactions with the server and a consistent interface for use in different platform APIs. Among your options is keepalive, which ensures that a request continues regardless of whether the page that made it remains open or not:
window . addEventListener ( 'unload' , {
fetch ( '/ siteAnalytics' , {
method : 'POST' ,
body : getStatistics ( ) ,
keepalive : true
} ) ;
}the fetch () The method has the advantage of more control over what is sent to the server. What I don't show in the example is that fetch () also returns a promise that is resolved with a Response object. Since I am trying to prevent the page from downloading, I chose not to do anything with it.
SendBeacon ()
it actually uses the Fetch API under the hood, which is why it has the same 64KB payload limitation and why it also ensures that a request continues after a page download. Its main advantage is its simplicity. It allows you to submit your data with a single line of code:
window . addEventListener ( 'unload' , {
navigator . sendBeacon ( '/ siteAnalytics' , getStatistics ( ) ) ;
}conclusion
With the greater availability of
fetch ()
in browsers, XMLHttpRequest () Hopefully, it will be removed from the web platform at some point. Browser vendors agree that it should be removed, but it will take time. Letting go of one of your worst use cases is a first step that improves the user experience for everyone.
Photo by Matthew hamilton in Unsplash
