(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
Version: 1.21.x
Severity: normal
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.
(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.
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.
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.
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.
(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
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?
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?
(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.
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. :-/