Is ResourceLoader 2 going to fix the issue with scripts loading after a significant delay after the rest of the page loads?
Topic on Talk:ResourceLoader/Flow
I don't intend to be a nag here, but the title for this thread and the contents of your message are somewhat addressing different, albeit overlapping, issues.
I'll answer them seperately.
Loading scripts from the top of the document
As of ResourceLoader 2 a module can be registered with one of various queue names. The default is 'bottom', which means the all-in-one load request will be initiated from the bottom of the page (after the output of the article, but stilll a fair distance away before the document-ready event).
This queue should be used to load scripts that affect the page independant from on-or-after-load scripts. A good example is the stylesheet that applies to HTML generated by PHP. For example Extension:CodeReview and Extension:LiquidThreads output HTML via PHP through Special pages and other means. The styling for this HTML should be loaded before the rest of the page is loaded (otherwise there'd be a moment of unstyled content, which is bad).
For these scenario's the "position" property of the module registry should be set to "top". Which means the module will be loaded from the top of the page and will, just like any <script> tag does in the <head>, block page execution untill it's parsed and executed.
Load delay
There were some issues in RL1 (most are fixed, some are pending) with the order and speed of the modules loaded. These should not be resolved by injecting the modules earlier (ie. "position" => "top") as this will either fail or have an effect that doesn't do what one might think (either way, it's evading the issue at hand).
Scripts that only affect a later state of the page or bind event handlers should not be loaded from the "top" (because these elements do not exist yet at that time, "top" basically means before <body> exists).
The reason that doing so might have side effects is due to dependancies. If a script wrongly puts itself in the "top" position and depends on another module (ie. jquery.ui.dialogs), that means that all of jquery.ui.dialogs (and it's dependancies: jquery.ui.core, jquery.ui.widget, jquery.ui.button etc. which also have dependancies that load) are now all loaded in the top of the page, because that one module needs it. That would slow down the page noticably.
If scripts execute with a delay, please report it as soon as possible. If you can, check out a copy of the current development trunk (svn checkout http://svn.wikimedia.org/svnroot/mediawiki/trunk/phase3 w) via Subversion so that you can see if the current solution and improvements work for you and solve the issues you had. (By doing that we can catch and resolve problems before you need to start thinking about work-arounds, because it's still in development and nothing is in release or deployment yet!)
On Wikimedia wikis, all site JS is loaded after a delay since 1.17 was launched. Everything from slight changes in things like tab appearance (w: only displays "Main Page" instead of "Article" a while after the page loads) to major DOM modifications (which is a necessity on some wikis) do not work optimally, causing the page to click/pop/jump into showing the right content after a delay instead of the way it used to be, with essentially zero delay in which the wrong content is displayed.
Indeed.
I still notice pages jumping, mostly when I click in the link to a specific section (e.g. of the village pump) and when the page finishes loading the section displayed is not the one I wanted. More info at:
- w:Wikipedia:Village_pump_(technical)/Archive_86#Jumping_to_the_wrong_section
- w:Wikipedia:Village_pump_(technical)/Archive_86#Jumping_page
- w:Wikipedia:Village_pump_(technical)/Archive_87#Edit_box_load_time
- w:Wikipedia:Village_pump_(technical)/Archive_87#Gadgets_stopped_working_again_.2F_Page_jumping
- Wikipedia:Village_pump_(technical)#Javascript_banner_lag_is_driving_me_insane
Wikipedia runs the latest almost-stable release of MediaWiki (currrently MediaWiki 1.17)
This was fixed in the live development branch ("trunk", currently aimed at MediaWiki 1.19). I've made and ran tests for this and they look at lot better than it did in 1.17.
If you feel like testing this yourself, please install MediaWiki yourself (from svn trunk that is, not from Download).
Like I said in the initial post, whether the page jupms right now in Wikipedia is not entirely relevant because nothing changed there. Wikipedia runs the latest (almost) stable version, not the development version that we are working on (eg. "the next version").
The development version is not stable yet for use on Wikipedia, however to verify that your issue has been resolved, please test it on the development version and not on the live site.
It would be crazy to apply this fix to Wikipedia before we know wether it actually works for all the use-cases. It would be helpful if you could install a copy of the Subversion development and see if the issue is resolved there.
Thanks.
Oh, and I really don't understand exactly how top-loading and JS delays are separate issues. If scripts are loaded at the bottom, there will always be a delay, unless I'm mistaken. How could the delay be removed unless the scripts are loaded before the content and the functions are activated immediately or almost immediately after the load of #footer? (And re: your example of the dependencies, I really doubt it's at all common that one would need complex jQuery modules immediately upon loading.)
My point exactly, I believe we are in agreement here!
If a script does not need a complex jQuery module tree, it should not be loaded in a way that is blocking page-display.
For example, suppose there's a script that enables one to do complex stuff with categorization in the "Categories: "-box on the bottom of the article through ajax queries and jQuery UI dialog boxes. That entire gadget (including all of the jQuery modules) don't have to be loaded before the article is displayed. Ideally this gadget would be seperated into two (or more) modules of which one is loaded in the head (the one that adds a button to the tabbar or whatever), and the rest of the script at the bottom.
Is there any way to do that, and have one gadget include multiple parts that are loaded at different points, the first part activating immediately and the second loaded later? (Note that in some cases it's necessary for a script to rework the entire content of a page, in which case all that matters is how long it takes between the bodycontent loading and the script starting to work, which will be longer than ideal unless the script was loaded before and nothing happens between #footer loading and $.ready() starting the function, so content-blocking doesn't matter in the slightest.)