We should improve the time it takes to load an item. Large items like https://www.wikidata.org/wiki/Q159 take way too long already and this will just get worse as more data is added.
This is a bug to track what needs to be done to improve the situation.
See Also:
T60085: TimedMediaHandler should not add start-up scripts
Repeating my bug 58106 comment 3:
This is caused by two problems, one of which is somewhat easy to fix when you
know what to look for (see below), and the other not so much.
The second problem is, obviously, the fact that *there's just so much code*,
and executing more code usually takes more time. I think even loading VE
requires less. Seriously, this is mad.
The first is that elements are sometimes first inserted into DOM, and then
"filled" with their children. This causes continuous reflows and repaints when
executing the script. The 81.82% "idle" time in Helder's log is spent on
reflows, repains and other related browser activities.
The worst offender here seems to be jquery.wikibase.entityview, which does
$( '<div/>' ).appendTo( this.element ).claimgrouplistview( { … } )
– where the .claimgrouplistview() call generates the entire list of claims that
spans several screens of text. If you scroll down during the loading of the
page, you can see the claims being built part-by-part in real time.
The obvious fix – changing the order of operations – seems to cause all of the
edit links not to appear (unless I borked something else). I did not
investigate the root cause, probably something somewhere ten levels of
abstraction deep calls .parent()/.closest(), which at that point returns an
empty collection due to the element being parentless. Somebody more
knowledgeable about the code will probably be able to track this down easily.
Just building the elements before inserting them to the DOM, not after, gives an about infinity-fold improvement.
Reflows and repaints are a minor issue. Detaching the entityView's node while initializing the entity view does not result in any significant performance improvement. There might be a little confusion about the log/chart posted in bug 58106. One major part of the 81.82% is spent before the entityViewInit's document ready event handler is even processed. The remaining idle time is spent after JavaScript initialization has finished (see flame chart).
Profiling current Q212, it takes about 1/3 of the overall loading time until entityViewInit's event handler is processed (on my machine). As to the flame chart in bug 58106, this would be at about 86 seconds with those 86 seconds being idle time nearly completely. That time contains some considerable amout of waiting for back-end responses. Beginning with 124 seconds, JavaScript initialization is finished followed by 2.4 minutes of idle time.
The major problem is, as pointed out, the sheer number of JavaScript code executed. Tons of jQuery widgets are initialized as soon as the page is loaded. A solution would be to defer initializing most of those widgets until they are actually needed. This would require a proper non-JavaScript page the "minimal" JavaScript could be initialized on. However, in order to achieve that, formatters need to be implemented properly in the back-end first. Currently, the front-end formatters for Time and GlobeCoordinate are more sophisticated than the ones in the back-end.
I'm commenting just to add keywords for searchability. HTH. :)
Warning: Unresponsive script
A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete.
It appears after ~15 seconds on Q254, during which the entire browser is unresponsive (all tabs), and look like this: http://i.imgur.com/BnjJ1qZ.png
(In reply to comment #6)
https://bits.wikimedia.org/www.wikidata.org/load.
php?debug=false&lang=en&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.
triggerQueueCallback%2CloadingSpinner%2CmwEmbedUtil%7Cmw.
MwEmbedSupport&only=scripts&skin=vector&version=20140110T032948Z:148
Also see bug 58085 for not loading TMH stuff on pages without multimedia.
Just to note how important the fix of this bug is. Using my Laptop, not a very good one but quite usable, I simply cannot open items containing lots of statements. Both Firefox and Chrome give me a message because of an "unresponsive script" every ~30 seconds for more than 10 times. Thus I also cannot view or edit this items which is a really hard fact and does affect lots of users afaik.
Something I have recognized is that the whole HTML for the statements is recreated via Javascript because you can see that after each "unresponsive script" dialog some more statements appear in the list. This should not be the way to go but the HTML should be created in the PHP part of the software. Javascript should only be responsible for clicking events etc. but it should *never ever* create tons of HTML and construct a whole web page.
So please take as much effort into that as possible because a database where the data cannot be viewed or edited does not make lots of sense.
Pages such as http://www.wikidata.org/wiki/Q5296 take over 30 seconds(!) to load while logged out. This is unacceptable performance.
(In reply to comment #11)
Pages such as http://www.wikidata.org/wiki/Q5296 take over 30 seconds(!) to
load while logged out. This is unacceptable performance.
We know. That's why this is set to major and that is why we're working on it for the past weeks.
(In reply to comment #12)
(In reply to comment #11)
Pages such as http://www.wikidata.org/wiki/Q5296 take over 30 seconds(!) to
load while logged out. This is unacceptable performance.We know. That's why this is set to major and that is why we're working on it
for the past weeks.
We need better documentation on how to investigate front-end performance issues, so if you can, please make notes about the way you are going about this work. It would be very helpful.
To clarify: the problem is not loading data, but initializing widgets. The
browser isn't waiting for the server, it's frantically running in circles trying
to get all the JS widgets set up. Which, of course, we should avoid. We are
working on it. Sorry for the inconvenience.
- daniel
Possible improvements of the code:
Closing this overarching epic tracking ticket that is years old and no longer really serves a useful purpose