Page MenuHomePhabricator

[Epic][UI] Front-end performance: Improve loading time of items
Open, HighPublic

Description

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

Details

Reference
bz54098

Related Objects

StatusAssignedTask
DeclinedNone
ResolvedLydia_Pintscher
ResolvedNone
OpenNone
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
Resolvedadrianheine
ResolvedNone
ResolvedNone
ResolvedNone
OpenNone
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
Resolvedthiemowmde
ResolvedNone
DeclinedNone
Resolvedthiemowmde
DeclinedLydia_Pintscher
DeclinedNone
OpenNone
Resolvedthiemowmde
InvalidNone
DeclinedNone
OpenNone
Openthiemowmde
Resolvedadrianheine
Resolvedadrianheine
Resolvedadrianheine
ResolvedNone
Resolvedadrianheine
InvalidNone
Declined Jonas
ResolvedNone
Resolvedadrianheine
Resolvedadrianheine
Invalidthiemowmde
Resolvedadrianheine
Resolvedthiemowmde
OpenNone
OpenNone
StalledNone
ResolvedLea_Lacroix_WMDE
ResolvedLucas_Werkmeister_WMDE
ResolvedLucas_Werkmeister_WMDE
Resolvedmatej_suchanek
ResolvedLea_Lacroix_WMDE

Event Timeline

bzimport raised the priority of this task from to High.
bzimport set Reference to bz54098.
bzimport added a subscriber: Unknown Object (MLST).
  • Bug 52458 has been marked as a duplicate of this bug. ***

Idea by Henning: Only initialize certain widgets when clicking edit.

  • Bug 58106 has been marked as a duplicate of this bug. ***

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. :)

The current error dialog in Firefox reads:

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.

Script: 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

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.

hoo added a comment.Jan 13 2014, 7:02 PM
  • Bug 59996 has been marked as a duplicate of this bug. ***
  • Bug 60102 has been marked as a duplicate of this bug. ***
Bene added a comment.Jan 17 2014, 10:47 PM

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.

ori added a comment.Feb 12 2014, 9:18 PM

(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

We've made good progress now so this is less pressing.

Lydia_Pintscher removed a subscriber: Unknown Object (MLST).
Lydia_Pintscher removed a subscriber: Unknown Object (MLST).Dec 1 2014, 2:31 PM
Lydia_Pintscher moved this task from incoming to hold on the Wikidata board.Mar 16 2015, 10:10 AM

Possible improvements of the code:

matej_suchanek set Security to None.
XXN removed a subscriber: XXN.Jul 13 2015, 9:55 PM
Jonas renamed this task from [UI] Front-end performance: Improve loading time of items to [Epic][UI] Front-end performance: Improve loading time of items.
Jonas added a project: Epic.
Agabi10 added a subscriber: Agabi10.Feb 3 2016, 2:43 PM
Krinkle removed a subscriber: Krinkle.May 16 2016, 1:18 PM
abian added a subscriber: abian.Nov 4 2018, 2:19 PM