Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Declined | None | T59765 Provide JavaScript hook | |||
Resolved | Lydia_Pintscher | T63131 Eliminate or reduce delay between selection of property and displaying of input fields when adding statements | |||
Resolved | None | T58090 Do not change targets to javascript:void(0); on JavaScript load for various "edit" links | |||
Invalid | None | T56098 [Epic][UI] Front-end performance: Improve loading time of items | |||
Declined | None | T118968 [Task] Investigate if removing of events improves loading times |
Event Timeline
I added log code to TemplatedWidget._trigger and found that an example item in my local repository with 31 snaks in 31 statements calls this._trigger 975 times on load. That's an awful lot, considering that most of these events do not have a listener.
When I disable all these events with a simple return, the duration of the final DOM load event (I assume this is the place where I can see the impact of these events in Firefox' performance monitor) goes down from 1200ms to 600ms.
Note that this experiment only covers ._trigger( calls. There are also a few .trigger( calls in our code base, e.g. in snakview.variations…
- 42 addtoolbarcreate
- 42 addtoolbarinit
- 5 aliasesviewcreate
- 5 aliasesviewinit
- 7 badgeselectorcreate
- 7 badgeselectorinit
- 4 closeablecreate
- 4 closeableinit
- 4 closeableupdate
- 5 descriptionviewcreate
- 5 descriptionviewinit
- 31 editabletemplatedwidgetcreate
- 31 editabletemplatedwidgetinit
- 35 edittoolbarcreate
- 35 edittoolbarinit
- 1 entitytermsforlanguagelistviewcreate
- 1 entitytermsforlanguagelistviewinit
- 5 entitytermsforlanguageviewcreate
- 5 entitytermsforlanguageviewinit
- 1 entitytermsviewcreate
- 1 entitytermsviewinit
- 1 itemviewcreate
- 1 itemviewinit
- 5 labelviewcreate
- 5 labelviewinit
- 63 listviewcreate
- 63 listviewinit
- 85 listviewitemadded
- 7 referenceviewcreate
- 7 referenceviewinit
- 1 sitelinkgrouplistviewcreate
- 1 sitelinkgrouplistviewinit
- 3 sitelinkgroupviewcreate
- 3 sitelinkgroupviewinit
- 3 sitelinklistviewcreate
- 3 sitelinklistviewinit
- 7 sitelinkviewcreate
- 7 sitelinkviewinit
- 9 snaklistviewcreate
- 9 snaklistviewinit
- 44 snakviewcreate
- 44 snakviewinit
- 1 statementgrouplistviewcreate
- 1 statementgrouplistviewinit
- 10 statementgroupviewcreate
- 10 statementgroupviewinit
- 10 statementlistviewcreate
- 10 statementlistviewinit
- 31 statementviewcreate
- 31 statementviewinit
- 77 toolbarbuttoncreate
- 77 toolbarbuttoninit
- 35 toolbarcreate
- 35 toolbarinit
How can something be in »consider for next sprint« when it's already half-done? Question could also be the other way round.
I was not aware of this ticket when I played around with that logging. I had this in mind for months, it took me 10 minutes, and I found it could be helpful if I would store it somewhere. If my commend irritates you, I can delete it.
I'm afraid there is nothing actionable here. That part of the jQueryUI based UI is very, very unlikely to ever be touched again.