Page MenuHomePhabricator

Loading CSS with ResourceLoader $wgOut->addModule method is very slow.
Closed, InvalidPublic

Description

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: https://code.google.com/p/mediawiki-book-manager/


Version: unspecified
Severity: enhancement

Details

Reference
bz27769

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:27 PM
bzimport set Reference to bz27769.

Can we reproduce this slowness somewhere in a clean install ?

Yes of course =D

  1. install normally.
  2. Import any book (this for example: ttp://pt.wikibooks.org/wiki/Categoria:Livro/Introdu%C3%A7%C3%A3o_%C3%A0_programa%C3%A7%C3%A3o)
  3. Then create a list of pages like this: http://pt.wikibooks.org/w/index.php?title=Wikilivros:Livros/Introdu%C3%A7%C3%A3o_%C3%A0_programa%C3%A7%C3%A3o&oldid=140619
  4. Finally remove the piece of code where is written "$ wgOut-> addModuleStyles ('ext.BookManager'); "

https://code.google.com/p/mediawiki-book-manager/source/browse/trunk/BookManager.body.php?r=35#305

PS:

A correction on the description of this bug:
Where has written: "injectStyleAndJS static function (& $ out, & $ sk) " is actually
"static function injectStyleAndJS (&$out, &$sk) "

I mean a clean install, just to proof/test this bug itself (loading css being bslow), not anything related to BookManager in any way.

ie.
Reproduce:

  1. Checkout SVN branch/REL1_17
  2. Create /extensions/Test/Test.php
  3. Put the following 4 lines in Test.php

....

  1. Edit LocalSettings.php and and include it
  2. See it load slow

Change the following lines in Test.php
and see it load fast.

happy.melon.wiki wrote:

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?

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.