What actually happens when a page opens a synchronous XMLHttpRequest with xhr.open('GET', url, false), and why do browsers treat that as deprecated?

## What the third argument does `xhr.open(method, url, async, user, password)` — `async` defaults to `true`. Passing `false` puts the object in synchronous mode, and the effect is entirely on `send()`: ```js const xhr = new XMLHttpRequest(); xhr.open('GET', '/config.json', false); xhr.send(); // returns only when the response is complete console.log(xhr.responseText); // already populated ``` The appeal is obvious — no callbacks, no state machine, the value is simply there on the next line. The cost is what makes it a deprecated feature. ## Why it is a main-thread hazard A document has one main thread, and it runs everything: script, the browser's event loop turn, style and layout, and the frame the compositor is waiting for. A blocking `send()` occupies that thread for the entire network round trip. During that window nothing else can be dispatched — a timer that came due, a click the user made, a scroll, a `MutationObserver` callback, an animation frame. The tab does not merely feel slow; it is unresponsive, and the operating system may show the "page is not responding" affordance. The duration is not yours to control. A same-origin request on a fast connection may take 20 ms in development and 8 seconds on a congested mobile network, and you cannot cap it — see the timeout restriction below. A hung server holds the tab until the browser's own network timeout fires. There is also a correctness dimension. Because no other task can interleave, everything the page would have done during that time is deferred and then executes in a burst, which produces layout jank and, in code that assumed interleaving, ordering surprises. ## The restrictions the platform imposes The specification does not merely discourage the mode — it removes capabilities from it inside a `Window`: - `open()` throws `InvalidAccessError` if `async` is `false` and either `xhr.timeout` is non-zero or `responseType` is not the empty string. You may not bound the block with a timeout, and you may not ask for a typed response; text is all you get. - Progress notifications are effectively absent — a synchronous request has no meaningful intermediate states to observe, since no script can run while it is in flight. - Chromium blocks synchronous XHR issued from page-dismissal handlers, which was historically the excuse people gave for using it. That first rule is the concrete gotcha in real code: the following throws, and the message names an error people do not recognise. ```js const xhr = new XMLHttpRequest(); xhr.responseType = 'json'; xhr.open('GET', '/data', false); // InvalidAccessError in a document ``` ## Where it is still legitimate Inside a `Worker` — a dedicated worker, a shared worker, or a service worker's startup script context — `XMLHttpRequest` is available and synchronous mode is not restricted in the same way, because blocking a worker thread does not block rendering or input. Worker code that wants a straight-line fetch of some configuration, without restructuring around callbacks, can legitimately use it. Even there it is a design smell if the worker also serves messages, because a blocked worker cannot process its message queue either. The other place it survives is old code you inherit: bootstrap scripts loading configuration before anything else, or legacy libraries. Those are the ones that show up as multi-second freezes in a performance profile as a single long task attributed to `send()`. ## How to replace it The replacement is structural, not a one-line swap: make the call asynchronous and give the code somewhere to wait. Wrap the XHR in a promise and `await` it, or use `fetch`. When the synchronous call sat at page bootstrap to fetch configuration before rendering, the better fixes are to inline the configuration into the initial HTML, or to render a shell and fill it in when the data lands. ## How to spot it in a codebase Grep for the literal third argument — `open(` followed by `, false)` — and check any library that has not been touched in years. In the browser, the console prints a deprecation warning naming synchronous XHR on the main thread, and a performance trace shows one long task whose stack bottoms out in `send()`. Because the block is synchronous, it will also inflate the metrics that track long tasks and input delay.