Right now I would honestly prefer to view all flow pages without JS. All of the functionality is still present (even if it does load separate pages) but this initial lazy / client side loading does not happen.

It's loaded in the bottom queue (similar to a lot of features), but it is not deferred. The point of the overlay is to prevent JS users from using the no-JS view accidentally.

@Krinkle: Would it make sense to load Flow JS in the top queue, so the browser doesn't first parse all the HTML, then fire the request for Flow JS? Or is that not how it works. In the post-async-RL world I don't know what top and bottom queue even mean any more.

One improvement here for the history pages could be rather than grey out / disable the whole page only disable / grey out the few links that the JS would be altering here?

In T108313#1636367, @Addshore wrote:

One improvement here for the history pages could be rather than grey out / disable the whole page only disable / grey out the few links that the JS would be altering here?

+1, especially on things like history pages. (Where for example, I expect navpopups to not work, until the page has fully loaded)

See also T73476: Saving a new topic can take >5s on beta labs

Change 243037 had a related patch set uploaded (by Mooeypoo):
[proof of concept] Selectively disable nojs pieces when loading Flow

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

I did a little bit of experimentation, with page loading times. Here's very rough numbers:

Testing time-to-fully-load in seconds, from ctrl-F5, whilst logged-in:
History page at https://fa.wikipedia.org/w/index.php?title=%D8%A8%D8%AD%D8%AB_%DA%A9%D8%A7%D8%B1%D8%A8%D8%B1:Ladsgroup&action=history

• 6, 2, 9, 8, 5, 5, 6, 5, 4, 6, 2, 5, 4

"Start a new topic" VE edit-window at https://fa.wikipedia.org/wiki/%D8%A8%D8%AD%D8%AB_%DA%A9%D8%A7%D8%B1%D8%A8%D8%B1:Ladsgroup

• 6, 2, 9, 2, 2, 1, 6, 2, 2, 1, 3

History page at https://www.mediawiki.org/w/index.php?title=Talk:Sandbox&action=history

• 5, 3, 2, 4, 4, 6, 6, 7, 5

"Start a new topic" VE edit-window at https://www.mediawiki.org/wiki/Talk:Sandbox

• 4, 2, 3, 3, 2, 2, 4, 2

Very rarely, and not during these tests, and not ever reproducibly, I experience exceptionally long page-load times. Circa 17 seconds.

Versus, loading a wikitext page (eg https://www.mediawiki.org/wiki/MediaWiki ) which typically takes 2-4 seconds.

See also T114550: Flow talk page on mediawiki.org takes 4 seconds to load

Change 244372 had a related patch set uploaded (by Mooeypoo):
Load ext.flow as module => 'top'

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

Change 244372 merged by jenkins-bot:
Load ext.flow as module => 'top'

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

Change 244824 had a related patch set uploaded (by Mooeypoo):
Lazy load the ReplyWidget editor

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

In ms

Note: compare after deploy.

Change 244824 merged by jenkins-bot:
Lazy load the ReplyWidget editor

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

Prior to the ReplyWidget change, I measured the document ready handler in flow-initialize.js taking about 1800ms. After this change it's about 800ms.

I get important feedback from sv.wp, fr.wp and zh.wp, where people have seen notable slowdowns during the past days. I hope this change will solve it :)

Checked in betalabs - DOMLoadEvent(and Load) - averages - seem to be lower than before:

*depends on History page length

Change 243037 abandoned by Mooeypoo:
[proof of concept] Selectively disable nojs pieces when loading Flow

Reason:
Experimental; No longer relevant.

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

I would just like to revisit this ticket an hand a big thanks to everyone that worked on speeding Flow up.
In particular the issue I had with JS loading blocking all interaction with a page is now gone!
Now I can interact with a Flow history page as soon is it initially loads!
Wooo!

.▀█▀.█▄█.█▀█.█▄.█.█▄▀　█▄█.█▀█.█─█
─.█.─█▀█.█▀█.█.▀█.█▀▄　─█.─█▄█.█▄█

:)