Aside from the top/bottom distinction for javascript, there is a similar distinction for stylesheets.

However, that distinction was only recently introduced (T97420). Let's see about undoing that first.

@Peter and @ori both found that this extra stylesheet request is hurting render and load time performance. b7c0e537ebb721 attempted to revert this, though that was reverted for unrelated reasons at the time.

Improvement in the "time to first painted" in T107399 is impressive. But do we have a way to measure how many of those "quickly painted" pages actually result in the "flash of unstyled content"?

Also, how does T107399 influence slower network connections? For example, when I was using Tor to access WMF wikis (which is pretty fast those days!) I was getting T115692 every time.

In T109837#1741621, @saper wrote:

Improvement in the "time to first painted" in T107399 is impressive. But do we have a way to measure how many of those "quickly painted" pages actually result in the "flash of unstyled content"?

To a first approximation, I'm confident no pages have a FOUC. T107399 doesn't affect that. The login and preference pages are isolated edge cases due to how they are uniquely constructed.

There are a few FOUCs mobile due to late loading of styles. However those are caused by late-loading of styles. They are not caused by any asynchronicity in the loading of scripts. This was a regression from T97420. This task (T109837) will resolve that by consolidating the queues back at the top of the page.

Merging the top and bottom script queues (both of which may be async already) will put more load on the top queue. While this is perfectly fine and will naturally scale (thanks to automatic batching and distribution). There is one problem: Cache hits.

The load.php requests created by mw.loader are naturally asynchronous. The startup module itself uses <script async>. However when the startup module is cached, it may execute synchronously during the critical path. On top of that, it will execute localStorage cache hits for required modules synchronously as well.

To avoid a performance regression there I'm gonna block this on T130855: Make mw.loader.store asynchronous.

What would be the best strategy to pre-select active tab based on the # on the preferences screen without causing the page to reflash (HTML, CSS and then pre-selecting code run in async)?

@saper I've replied at T115692.

Removed T130855 as blocker. After thinking about this some more with @ori, I realised the store is not a dependency. It's fine to fetch items from the store one by one (it's just a plain in-memory object anyway; we only fetch from localStorage once for the whole blob).

Rather, the dependency is that execution of code fetched from mw.loader.store needs to be async (one per item instead of all at once). This is done in mw.loader.work.

T142129: Source code eval should be async in mw.loader.work

Change 320315 had a related patch set uploaded (by Krinkle):
resourceloader: Remove top/bottom queue distinction

https://gerrit.wikimedia.org/r/320315

Change 320315 merged by jenkins-bot:
resourceloader: Remove top/bottom queue distinction

https://gerrit.wikimedia.org/r/320315