Last modified: 2014-11-17 10:35:46 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T29620, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 27620 - Edit toolbar loads siginficiantly slower with the Resource loader or BannerLoader
Edit toolbar loads siginficiantly slower with the Resource loader or BannerLo...
Status: RESOLVED WORKSFORME
Product: MediaWiki
Classification: Unclassified
ResourceLoader (Other open bugs)
1.17.x
PC Windows 7
: Normal normal with 4 votes (vote)
: ---
Assigned To: Trevor Parscal
http://pl.wikipedia.org/wiki/no-page-...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-02-21 22:10 UTC by Nux
Modified: 2014-11-17 10:35 UTC (History)
9 users (show)

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


Attachments

Description Nux 2011-02-21 22:10:13 UTC
Steps:
1. Open an example page (I'm using pl.wiki because you can't edit a page on en.wiki while not logged in)
2. Reload the page (normal reload).

Results:
Page loads significantly slower then with 1.16.

Expected results:
Should load faster (as RL is on now).

This is more significant in Firefox 3.6 then in 4.0 or in Opera 11, but I can still start editing before the page is loaded and only when the page is loaded the toolbar loads. This causes loose of focus and cursor position.

The page loads for about 6-9 seconds (as measured by Firebug) and there are 2-3 gaps in a net tab before loading the following resources:
http://pl.wikipedia.org/w/index.php?title=MediaWiki:Api.js&action=raw&ctype=text/javascript
http://pl.wikipedia.org/w/index.php?title=Specjalna:BannerListLoader&cache=/cn.js&language=pl&project=wikipedia&country=PL
http://meta.wikimedia.org/w/index.php?title=Special:BannerLoader&banner=WMPL_Wikimedia_Polska_Conference&userlang=pl&db=plwiki&sitename=Wikipedia&country=PL

So the problem might be BannerLoader related (api usually loads faster). The server seems to always respond with 200 rather then 304 for those two. Not sure why it is needed (if it is). JS should be loaded just once and some random banner should be loaded but the response for the loaded banner should always be 304. And I'm sure both should not be loaded if the banner is hidden.
Comment 1 Nux 2011-02-21 22:15:55 UTC
BTW wouldn't it be faster to have all banner on a statical page loaded (refreshed e.g. twice a week) and just pick a random one from the list (filtering the list with JS for current user)? The banners seems short enough.
Comment 2 Ryan Kaldari 2011-02-24 05:42:52 UTC
The slowness of BannerLoader is because the script has to lookup your location based on your IP address before it decides which banner to serve (and it doesn't even start this until the page is finished loading). We may want to change this so that your location is stored in a cookie instead.

Regardless, CentralNotice/BannerLoader is probably the only JavaScript component that didn't change with the new 1.17 deployment (since it was already loading everything on document.ready to start with). So it's very unlikely the BannerLoader is responsible for any recent changes in toolbar loading.
Comment 3 Krinkle 2011-02-24 08:39:06 UTC
May not be related but I noticed the other day that BannerLoader is causing a 302 redirect (not a 301 or 303) on all page views of non-English content language wikis.

The url is constructed like :

wgServer,
wgScript,
?title=[localized namespace name for Special],
:BannerListLoader
&etc etc.

"BannerListLoader" is put there in English, causing a redirect to the localized version (ie. "Speciaal:Bannerlijstlader" on nl.wikipedia)

Can the special page _name_ be translated in the url construction, just like the namespace name is localized ?
Comment 4 Ryan Kaldari 2011-02-24 19:30:43 UTC
It seems the behavior of special page aliases is the opposite of what is described at http://www.mediawiki.org/wiki/Manual:Special_pages#The_Alias_files. Was this switched around at some point?

Also, is there a more elegant way of retrieving the localized alias besides:
if ( $specialPageAliases[$wgContLang]['BannerListLoader'][0] ) {
  return $specialPageAliases[$wgContLang]['BannerListLoader'][0];
} else {
  return 'BannerListLoader';
}

I imagine there's some specialized get method for this, but I haven't found anything yet.
Comment 5 Nux 2011-02-24 21:06:34 UTC
(In reply to comment #2)
> The slowness of BannerLoader is because the script has to lookup your location
> based on your IP address before it decides which banner to serve (and it
> doesn't even start this until the page is finished loading). We may want to
> change this so that your location is stored in a cookie instead.

That may be one way but you could also check this for all users based on there most common IP and decide for them. Then you could write it to preferences after a user would confirm that this is his location (something similar is happening in Youtube). That way all this geolocalization and banner stuff could run once and be done for. Users could change their localization/country in preferences (near the language) and they could choose it after registering.

> Regardless, CentralNotice/BannerLoader is probably the only JavaScript
> component that didn't change with the new 1.17 deployment (since it was already
> loading everything on document.ready to start with). So it's very unlikely the
> BannerLoader is responsible for any recent changes in toolbar loading.

I'm guessing loading sequence changed with RL, so that might be a bit more of a pain now. Or maybe caching is still a bit unstable.

BTW could you load banner script only if banners are not disabled? Something like:
  if (document.cookie.indexOf('hidesnmessage=1')==-1)
    mw.loader.load(wgServer + wgScriptPath + '?title=Special:BannerController&cache=/cn.js')

It's pointless to load it if it is not going to be used and it might help in page loading speed. Same might apply for the geo stuff...
Comment 6 Ryan Kaldari 2011-02-24 22:13:33 UTC
That sounds like a good idea (checking the hide cookie before loading).

In case anyone's interested, the answer to my earlier question is:
$wgContLang->specialPage( $pageName )

I'll implement both of these fixes some time in the next couple weeks.
Comment 7 Ryan Kaldari 2011-02-24 22:24:35 UTC
Fix to avoid redirect checked into r82749.
Comment 8 Nux 2011-03-01 22:43:56 UTC
I'm almost certain now that all this problems are based in one thing - scripts (all scripts) were moved from head to the bottom of a page.

I know it is supposed to make pages load faster but it's just not working. Many users on pl.wiki complain that pages load slower and jump back and forth while portlets and toolbars are added (by scripts).
Comment 9 Ilmari Karonen 2011-03-08 15:20:03 UTC
I wonder if implementing the suggestion I made in bug 25860 would solve at least some of this?
Comment 10 WlaKom 2011-03-08 23:21:42 UTC
See my comments on the Bug 27488.
Comment 11 Nux 2011-03-08 23:34:16 UTC
(In reply to comment #9)
> I wonder if implementing the suggestion I made in bug 25860 would solve at
> least some of this?

I don't think so. The problem is that the elements are already being displayed __before__ the scripts even start loading. It's the way HTTP/HTML works. This is why some suggest that you should put scripts on the bottom of the page so the page can load before the scripts do. The problem is it is not working when a user want to and should (!) wait for the scripts to load before he does anything to the page. I think it just doesn't work for wiki and should be changed or at least users should be able to decide what does they want.
Comment 12 Ryan Kaldari 2011-03-09 02:40:43 UTC
The BannerListLoader issue on non-english wikis is fixed on the live wikis now.
Comment 13 Nux 2011-03-12 12:55:48 UTC
I see a significant difference now, so I consider this fixed. Thanks :-).
Comment 14 AlexSm 2011-03-22 15:05:14 UTC
However the textarea still loses focus after the new toolbar is loaded and you can even type some characters before this happens. This is easily reproduced on Wikipedia in Firefox 3.6.15 and Opera 11.01 but not in Chrome.

Are there any plans to fix that?
Comment 15 Nux 2011-03-23 18:14:56 UTC
This is in Bug 27488. AFAIK it's impossible to fix it otherwise.

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


Navigation
Links