Last modified: 2012-06-20 03:34:00 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 27769 - Loading CSS with ResourceLoader $wgOut->addModule method is very slow.
Loading CSS with ResourceLoader $wgOut->addModule method is very slow.
Product: MediaWiki
Classification: Unclassified
ResourceLoader (Other open bugs)
All All
: Normal enhancement (vote)
: ---
Assigned To: Trevor Parscal
Depends on:
  Show dependency treegraph
Reported: 2011-02-27 21:19 UTC by Raylton P. Sousa
Modified: 2012-06-20 03:34 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description Raylton P. Sousa 2011-02-27 21:19:39 UTC
When I use the  code below, CSS is taking too long to load:

injectStyleAndJS static function (& $ out, & $ sk) {
                 global $ wgOut;
                 $ wgOut-> AddModule ('ext.BookManager');
                 return true;

and this is only solved when I use addModuleStyles to call the same function:

static function injectStyleAndJS( &$out, &$sk ) {
                global $wgOut ;
               $wgOut->addModuleStyles( 'ext.BookManager'); 
                $wgOut->addModules( 'ext.BookManager'); 
                return true;

and that to me seems a redundant.
The extension code where the error occurs here:
Comment 1 Krinkle 2011-02-27 21:22:03 UTC
Can we reproduce this slowness somewhere in a clean install ?
Comment 2 Raylton P. Sousa 2011-02-27 22:20:12 UTC
Yes of course =D
1. install normally.
2. Import any book (this for example: ttp://
3. Then create a list of pages like this:
4. Finally remove the piece of code where
 is written "$ wgOut-> addModuleStyles ('ext.BookManager'); "

A correction on the description of this bug:
Where has written: "injectStyleAndJS static function (& $ out, & $ sk) "  is actually  
"static function injectStyleAndJS (&$out, &$sk) "
Comment 3 Krinkle 2011-02-27 22:33:19 UTC
I mean a clean install, just to proof/test this bug itself (loading css being bslow), not anything related to BookManager in any way.

1. Checkout SVN branch/REL1_17
2. Create /extensions/Test/Test.php
3. Put the following 4 lines in Test.php
4. Edit LocalSettings.php and and include it
5. See it load slow

Change the following lines in Test.php
and see it load fast.
Comment 4 Raylton P. Sousa 2011-02-28 01:04:07 UTC
I made a small extension which only serves to format the header, it serves?
Comment 5 Happy-melon 2011-03-05 15:21:56 UTC
This is, AFAICT, the same problem as bug 27488: styles loaded dynamically with RL are loaded at the end of the page, so are not applied immediately: there is a moment on page load when the styles are not applied, then they 'jump' into play.  Is that right?
Comment 6 Krinkle 2012-06-20 03:34:00 UTC
This bug is not (directly) related to bug 27488 and it is an invalid bug, too.

The problem Raylton describes is not invalid, but he should use a different method in his extension.

By default it is assumed that a module contains code to dynamically enhance the page. Therefore it is loaded from the bottom of the page (after the article content is parsed, but before the ready/load events are fired).

This is done so that the page loads much quicker (no need to load 100s of modules that don't visibly change the page). If they were all loaded from the top (<head>), then all these modules would block visibility of the page and the user would see a blank page until the modules are loaded and executed before the browser can continue parsing the page. This is simply how browsers work.

Now of course there are numerous cases where a module must be loaded before the page is parsed. I'll briefly name two cases and how to deal with that.

*  A module that *only* contains styling (no scripts) and affect html elements that are outputted by PHP (for example skin css). This should be loaded in memory before the article is parsed (else the styling would cause a blink afterwards). Also, these modules should be loaded regardless of whether or not javascript is supported. In that case, OutputPage::addModuleStyles should be used. That's exactly what it is designed for, that is not a work around, but the intended solution.

* A module that contains styling or scripts (or both) that do something visible to the page immediately (e.g. add a link to the sidebar, or collapse an infobox). In that case you should set 'position' => 'top' in the module registry and just use the regular OutputPage:addModules(). The position property will add it to the load queue in the <head> (instead of the <body>). If your module contains scripts, then don't forget to wrap them in jQuery(document).ready(), otherwise it will fail, because in the <head> the <body> does not exist yet (e.g. #content will not exist yet). This is just how javascript works, and not something caused by MediaWiki or jQuery.

Note You need to log in before you can comment on or make changes to this bug.