sendBeacon vs xmlhttp (keeping the page unload and visibility out of picture)

Is using sendBeacon in place of xmlhttp more performant is the confusion I was trying to resolve for few days. Any pointer would be really helpful.

So, the use case is what happens when sendbeacon is used in place of xmlhttp(async) for requests made from a page's javascript in general (Various resources seem to focus only on the unload and visibility change part of it, where you want to send some data and there sendbeacon performs better).

Few questions here:

1. The javascript code from where I fire the request, is executed in the main thread of render process of browser, when it makes the xmlHttp send (async) call with an onreadystatechange listener, the request is delegated to the network process and the main thread can continue with its work in parallel (what happens in case of synchronous xmlhttp?) ? and the onreadystatechange listener code is run again by main thread and it will eat up CPU cycles from main thread?

2. How is the above process different if I use sendBeacon ? The sendBeacon queue and it processing is managed by which process and thread? It doesn't have the listener overhead and the browser can schedule and execute it entirely on a separate thread (is this a thread in the network process? ) ?

3. In which case fps will be high ? (it's directly related to how much main thread and compositor is free and not blocked by javascript either in the same thread or response on an IPC between main thread and compositor correct?

Some refs that I looked into:

1. Chrome multithreading
2. Using sendBeacon