Page MenuHomePhabricator
Create Task
Maniphest T60192

Investigate WikiLove's performance
Closed, DeclinedPublic
Actions

Description

We should investigate whether we can improve WikiLove's performance.

When I visit https://en.wikipedia.org/wiki/User:Brandon while logged in and call mw.loader.inspect() from the browser's console, I see:

0 jquery.ui.core 51.8 kB
1 ext.wikiLove.startup 49.6 kB
2 jquery.ui.button 25.4 kB

[...]

I also see:

0 jquery.ui.core 225 0 0.00%
1 ext.wikiLove.startup 60 0 0.00%
2 jquery.ui.button 43 0 0.00%

[...]

(The jquery entries are only provided for context, I don't believe they're related to WikiLove.)

Focusing _only_ on the WikiLove-related entries, these seem high, given that upon page load, the user has not interacted with (and likely will not interact with) WikiLove.

This can likely be optimized.

Version: unspecified
Severity: normal
See Also:
T54757: Move WikiLove user preference to "Editing" tab

Details

Reference
bz58192

Related Objects
Search...

Event Timeline

• bzimport raised the priority of this task from to Medium.Nov 22 2014, 2:32 AM
• bzimport added projects: WikiLove, Performance Issue.
• bzimport set Reference to bz58192.
• bzimport added a subscriber: Unknown Object (MLST).
• MZMcBride created this task.Dec 9 2013, 3:00 AM
Legoktm added a comment.Dec 9 2013, 3:04 AM

(In reply to comment #0)

(The jquery entries are only provided for context, I don't believe they're
related to WikiLove.)

ext.wikiLove.startup has dependencies upon jquery.ui.dialog, jquery.ui.button, jquery.localize and jquery.elastic.

kaldari added a comment.Dec 9 2013, 6:41 PM

The extension could be refactored so that most of the JS code and dependencies are only loaded once the user clicks on the WikiLove icon. We would need to at least pre-load jquery.ui and jquery.ui.dialog though so that something happens immediately when you click the icon, even if it's just a spinner in a box. I imagine that would reduce the footprint by about half. The jquery.elastic code could probably be removed completely at this point since most browsers support resizable textareas natively now.

Unfortunately, WikiLove doesn't have a maintainer at the moment and optimizing pageload for such a specific situation (logged in users on other people's user pages) isn't high priority. This would, however, be a nice project for a volunteer.

• MZMcBride added a comment.Dec 9 2013, 10:16 PM

Tentatively marking this bug with the "easy" keyword.

yuvipanda added a comment.Feb 5 2014, 9:59 PM

I've removed jquery.elastic in https://gerrit.wikimedia.org/r/#/c/111534/ and gotten rid of jQuery UI buttons in https://gerrit.wikimedia.org/r/#/c/111511/2. I think the Dialog dependency is going to stay (for now, at least). I am unsure if localize is used at all in the code - will take a look a bit later.

Aklapper added a comment.Feb 6 2014, 9:01 AM

(In reply to comment #3)

Tentatively marking this bug with the "easy" keyword.

I don't see how performance testing and fixing is something for beginners.

• MZMcBride added a comment.Feb 7 2014, 2:14 AM

(In reply to comment #5)

(In reply to comment #3)

Tentatively marking this bug with the "easy" keyword.

I don't see how performance testing and fixing is something for beginners.

The keyword was added following comment 2, which laid out a pretty clear course of action to resolve this bug report. Nobody was asking new developers to create performance instrumentation tools or anything like that. The request here was to look at a browser's standard dev tools and try to find and implement a few small optimizations. This is exactly what Yuvi seems to have done (thanks, Yuvi!).

Legoktm added a comment.Jul 12 2015, 4:24 AM

There are some other performance improvements that can be made by adding the proper caching parameters to different API requests made by the JS. T89815: Convert WikiLove from jQuery UI to OOUI will also be a perf improvement since most of the custom jQuery libraries can be dropped.

Restricted Application added a project: Collaboration-Team-Triage. · View Herald TranscriptJul 12 2015, 4:24 AM
Krinkle added a subtask: T64000: WikiLove: Stylesheet should not embed both png and svg version of image.Mar 8 2016, 9:21 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 8 2016, 9:21 PM
Catrope closed subtask T64000: WikiLove: Stylesheet should not embed both png and svg version of image as Resolved.Mar 10 2016, 8:40 PM
• Phabricator_maintenance removed a subscriber: yuvipanda.Jun 7 2017, 7:01 PM
Liuxinyu970226 updated the task description. (Show Details)Sep 4 2018, 2:34 PM
Restricted Application added a project: Growth-Team. · View Herald TranscriptSep 4 2018, 2:34 PM
Krinkle removed a parent task: T57683: Bugs caught by mw.loader.inspect() (tracking).May 8 2019, 1:59 PM
Krinkle edited projects, added Performance-Team (Radar); removed Performance Issue.
Krinkle removed a subscriber: • wikibugs-l-list.
Krinkle closed this task as Resolved.May 8 2019, 3:35 PM
Krinkle subscribed.

Marking as fixed, because:

  • All JavaScript, as of 2015, is loaded asynchronously and thus not blocking page rendering anymore.
  • The module that the WikiLove extension now queues directly, is ext.wikiLove.init which is relatively small. The other is a lazy dependency run after dom-ready.
  • It's only loaded on user pages, which aren't as performance critical compared to reading articles, history, sign up, user contribs etc when it comes to reading and contributing (as far as I know). And even then, the only cost we pay there is bandwidth and while 49KB (note: measured without compression yet) is still pretty significant in 2019 in terms of render-blocking cost, in terms of async bandwidth somewhere on the page, is not as critical I think. The overall page (enwiki, User:Brandon) adds to 2.0 MB for me logged-in (uncompressed), making this only 3% of it overall.

Certainly something that can be optimised, and if it were elsewhere in a user workflow, might be higher priority, but closing for now as perf isn't pushing for it at the moment, and the extension doesn't seem to have resourcing beyond basic maintenance. We could keep it open as generic reminder that "something can be optimised", but that doesn't seem particularly useful. If and when time is available for this extension and/or user pages in general, I'm sure it'll come up as self-evident.

Krinkle changed the task status from Resolved to Declined.May 8 2019, 3:36 PM
kaldari added a comment.May 8 2019, 3:45 PM

Thanks for your work on this, @Krinkle!

Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL · Credits