"Krinkle" posted a comment on MediaWiki.r108184.
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/108184#c29034
Commit summary for MediaWiki.r108184:
ResourceLoader: Add an experimental option to move the main module loading
queue (the bottom queue) from the bottom of the <body> up into the <head> ,
while still being loaded asynchronously. This makes them load earlier, which
should make the page load faster. This is the product of a long discussion on
bug 27488
* Added a "blocking" state to mw.loader . When loading scripts while the
document is not ready, the loader will use document.write() if blocking is
true, and append to the <body> or the <head> if blocking is false. If the
document is ready, the loader will always append to the <body>
* Enable blocking mode while loading the top queue, and disable it after. This
ensures that modules in the top queue are still loaded in a blocking way as
they were before
* If $wgResourceLoaderExperimentalAsyncLoading is true, the bottom queue is
also loaded in the head, but with blocking mode disabled. Otherwise, it's
loaded at the bottom of the <body> as before
* scripts-only and messages-only requests need special treatment:
** in the top queue, they can continue to use <script src="..."> tags because
they are blocking
** if the bottom queue is at the bottom of the <body> (experimental async
loading disabled), they can continue to use <script src="..."> tags as before
** if the bottom queue is in the <head> (experimental async loading enabled),
they cannot use <script src="..."> tags, because those would block. Instead,
call mw.loader.load() on the load.php URL
Krinkle's comment:
In very old Firefox versions and all versions of Opera, the document ready
event is delayed until after the default ('bottom') queue is loaded. This is
not a huge problem, and besides, there is nothing we can do about it, and it's
also the case for the current ResourceLoader technique in MediaWiki 1.18 as
well as before MediaWiki 1.17 and ResourceLoader, so not new.
What was a regression (or more of a side-effect) is that due to the fact that
Opera is the only browser not offering "async" for script tags, anything in
document after the load command for the default queue, will remain invisible /
not rendered, until after that queue is loaded. This was also the case before
this change, however, previously that load command was at the bottom of the
body, so there is nothing left to block. Since we're now doing it from the
HEAD, it is blocking the page content.
Short summary about scripts and async behavior:
:Scripts tags naturally in the document or inserted via
<code>document.write</code> are blocking further rendering and also block each
other and do so in order. Script DOM elements inserted are asynchronous by
default (except for Opera), this is true for new browsers (as they support the
HTML5 <code>async</code> property and have it set to true for default), as well
as for old browsers (which didn't offer the <code>async</code> property but
have been loading them asynchronously by default without a way to do otherwise,
and have been doing so for a long time)
_______________________________________________
MediaWiki-CodeReview mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
