Following T107399, the top queue is now asynchronous.
In fast environments this means the page is "loaded" before the startup module arrives and and top queue starts. As such the top and bottom queues may actually execute round about the same time.
There are two aspects here to consider:
Load priority. The separation means some scripts start loading early, and other scripts load late. In between is essentially content resources (e.g. images). With limited bandwidth, regardless of SPDY/HTTP2, there could be value in loading scripts in two stages instead of one so that higher priority scripts (define?) may arrive earlier and don't block images bandwidth-wise. It being asynchronous means it's no longer blocking the parsing and rendering of html, but that doesn't mean we magically doubled the bandwidth available to users.
Execution priority. This is tightly coupled with the previous point. The top queue being asynchronous means first paint can occur before script execution of any kind. However that isn't a requirement. In slow and uncached environments the top and bottom scripts will likely load and execute around the same time. However in fast or cached environments (e.g. repeated visits) the top and bottom scripts do execute at notably different times.
There is also a caveat in that when we previously tried to move the "bottom" queue to start asynchronously at the top of the body, various scripts broke due to the assumption that some scripts would run after the main content is parsed (e.g. dom-ready-ish to have certain elements available). We'll need to identify those and ensure they are bound to `$()` or `DOMContentLoaded` accordingly. This will also cause impact on user scripts and gadgets that make bad assumptions about execution time. Though in my experience gadgets already use dom-ready handlers correctly already (especially due to how before 2010 (pre-ResourceLoader) scripts were all at the top. This agrees with the mw-js-deprecate metric that `addOnloadHook` is by far the most popular method. I suspect the majority of issues with missing dom-ready handlers will come from Wikimedia-maintained extensions and MediaWiki core.