Last modified: 2014-09-18 13:21:07 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 T44532, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 42532 - Mediawiki:Common.js loading slowly/late
Mediawiki:Common.js loading slowly/late
Status: UNCONFIRMED
Product: MediaWiki
Classification: Unclassified
JavaScript (Other open bugs)
1.21.x
All All
: Low normal (vote)
: ---
Assigned To: Nobody - You can work on this!
: performance, testme
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-11-29 09:19 UTC by Yair Rand
Modified: 2014-09-18 13:21 UTC (History)
4 users (show)

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


Attachments

Description Yair Rand 2012-11-29 09:19:03 UTC
(This bug is specifically for version 1.21wmf5, but that doesn't seem to be an option in the version list, so I selected 1.21-git. I don't know if that's the same or what.)

The site JS loaded from Mediawiki:Common.js is taking a very long time to load/run. The DOM is finished loading about 4-5 seconds before the JS starts running. 

Example page: https://en.wiktionary.org/wiki/free
Comment 1 Sam Reed (reedy) 2012-11-29 09:22:29 UTC
Which browser? In Chrome it seems to load at a normal speed
Comment 2 Yair Rand 2012-11-29 09:24:22 UTC
I'm using Chrome on Windows 7.
Comment 3 Yair Rand 2012-11-29 09:27:05 UTC
Please make sure you're actually waiting for the site JS to load, and not just the other JS. There is a point at which other JS runs, when it looks like the page is "finished", and the site JS won't load until a while later.
Comment 4 Andre Klapper 2012-11-29 10:47:36 UTC
(In reply to comment #0)
> (This bug is specifically for version 1.21wmf5, but that doesn't seem to be an
> option in the version list, so I selected 1.21-git. I don't know if that's the
> same or what.)

It is.
Comment 5 Dennis C. During 2012-12-06 21:34:05 UTC
I am experiencing a similar short delay at en.wikt using FF 16.02. Two users left comments saying they experienced much more delay. They would not have had any custom JS. They are not likely to be reachable for more information on their browsers etc.
Comment 6 Andre Klapper 2012-12-11 12:03:57 UTC
When running Firefox using a fresh profile and/or safe mode would be good. 
In general this report so far doesn't have enough info to reproduce.
Comment 7 Dennis C. During 2012-12-11 16:53:41 UTC
To help me contribute to better triage on the performance problems at en.wikt is there documentation on performance issues? I don't even understand the loading sequence. Our major performance issues are almost certainly in our language- and script-handling template scheme, especially associated attempts at error-trapping. We also have some problems with some dynamically created load-time lists.
Comment 8 Andre Klapper 2012-12-17 11:49:30 UTC
(In reply to comment #7)
> To help me contribute to better triage on the performance problems at en.wikt
> is there documentation on performance issues?

Only things I am aware of are http://www.mediawiki.org/wiki/Manual:How_to_debug and http://www.mediawiki.org/wiki/ResourceLoader/Features#Debug_mode
Comment 9 Andre Klapper 2014-03-18 01:10:22 UTC
I don't see any slow loading on https://en.wiktionary.org/wiki/free nowadays, less than three seconds (cold; without cache; Firefox 27; no custom CSS/JS).

Is this still a problem?
Comment 10 Andre Klapper 2014-04-11 15:51:51 UTC
I don't see any slow loading on https://en.wiktionary.org/wiki/free nowadays, less than three seconds (cold; without cache; Firefox 27; no custom CSS/JS).

Is this still a problem?
Comment 11 Dennis C. During 2014-04-11 22:08:54 UTC
(In reply to Andre Klapper from comment #10)
> I don't see any slow loading on https://en.wiktionary.org/wiki/free
> nowadays, less than three seconds (cold; without cache; Firefox 27; no
> custom CSS/JS).
> 
> Is this still a problem?

It has sporadically occurred perhaps a dozen times this past year at English Wiktionary, sometimes affecting many users over many hours or a few days, sometimes for shorter intervals or for fewer users. It may be the product of something Wiktionary-specific as there has been lots of tinkering going on, by persons are varying technical capabilities, all however having capabilities exceeding mine. 

We seem to have some very ambitious ways of handling languages and scripts because of the peculiar needs of a dictionary that seeks to include "all words in all languages" in the native scripts of each. But use of very large Lua/Scribunto modules and data table has improved loading performance of entries such as that for "water". I don't know in what technical ways we differ peculiarly from other wikis, even from other wiktionaries. 

You are stuck with my naive reporting because those more capable seem to get more frustrated in dealing with WM.
Comment 12 Andre Klapper 2014-09-18 13:21:07 UTC
Would be great if this was brought up again in a timely manner whenever happening again. These problems are hard to debug and currently it's not very actionable for a developer to take a look at this, unfortuantely. :-/

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


Navigation
Links