Last modified: 2014-02-07 02:14:40 UTC
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.
(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.
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.
Tentatively marking this bug with the "easy" keyword.
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.
(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.
(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!).
