If you are know how to use your browser's JavaScript console, you can now get an ordered list of all ResourceLoader modules that are loaded on the page, sorted by the total size of each module's JavaScript and CSS assets -- simply run "mw.loader.inspect();".
It works best in newer versions of Chromium / Chrome, where it takes advantage of the availability of console.table(). It looks like this: http://i.imgur.com/zGymrsF.png
In the course of testing this feature yesterday, Matt Flaschen spotted and fixed redundant module loading in TimedMediaHandler (see bug 55550). That's pretty cool, no?
Do remember that size != performance, though -- just because a module is small does not mean that it is performant. (The reverse is also true.) This tool also does not account for factors like gzip compression. So no burning developers at the stake, please :) But curious poking is definitely encouraged.
Thanks to Timo & Roan for helping this along.
--- Ori Livneh ori@wikimedia.org
Nice feature, thanks!
1. I tried to use it in ?debug=1 mode, and it seems to give 0 size to many modules. 2. It would be nice if it would also give details about dependent modules (inclusive size vs exclusive size). for example when using ve with ?debug=1 and inspecting the net panel, it looks like DOS attack with hundreds of requests, and having both the inclusive and exclusive size would allow developers to understand the net effect of loading a module.
Eranroz
On Fri, Oct 11, 2013 at 3:19 AM, Ori Livneh ori@wikimedia.org wrote:
If you are know how to use your browser's JavaScript console, you can now get an ordered list of all ResourceLoader modules that are loaded on the page, sorted by the total size of each module's JavaScript and CSS assets -- simply run "mw.loader.inspect();".
It works best in newer versions of Chromium / Chrome, where it takes advantage of the availability of console.table(). It looks like this: http://i.imgur.com/zGymrsF.png
In the course of testing this feature yesterday, Matt Flaschen spotted and fixed redundant module loading in TimedMediaHandler (see bug 55550). That's pretty cool, no?
Do remember that size != performance, though -- just because a module is small does not mean that it is performant. (The reverse is also true.) This tool also does not account for factors like gzip compression. So no burning developers at the stake, please :) But curious poking is definitely encouraged.
Thanks to Timo & Roan for helping this along.
Ori Livneh ori@wikimedia.org _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
This is interesting Ori - thanks for sharing this / setting it up.
Sorry to pick on this example in particular but I was surprised to see so much code for the Universal Language selector (ULS) - especially as a single language speaker I don't ever use any of them - and I am thus being penalised. This feature can surface to us situations like this which we ought to be more cleverer in how we load them - for instance I imagine the code for ULS could be loaded on demand when I express a desire for other languages - e.g. click a button.
FYI on mobile it doesn't work: I assume this just doesn't make use of targets in RL to allow it to run on mobile? Looking at network tab it doesn't seem to add any weight to the startup module / page load itself and gets pulled down when needed so from my perspective it would be a useful tool to have on mobile! :)
mw.loader.inspect() Error: Unknown dependency: mediawiki.inspect
On Thu, Oct 10, 2013 at 10:03 PM, Eran Rosenthal eranroz89@gmail.com wrote:
Nice feature, thanks!
- I tried to use it in ?debug=1 mode, and it seems to give 0 size to many
modules. 2. It would be nice if it would also give details about dependent modules (inclusive size vs exclusive size). for example when using ve with ?debug=1 and inspecting the net panel, it looks like DOS attack with hundreds of requests, and having both the inclusive and exclusive size would allow developers to understand the net effect of loading a module.
Eranroz
On Fri, Oct 11, 2013 at 3:19 AM, Ori Livneh ori@wikimedia.org wrote:
If you are know how to use your browser's JavaScript console, you can now get an ordered list of all ResourceLoader modules that are loaded on the page, sorted by the total size of each module's JavaScript and CSS assets -- simply run "mw.loader.inspect();".
It works best in newer versions of Chromium / Chrome, where it takes advantage of the availability of console.table(). It looks like this: http://i.imgur.com/zGymrsF.png
In the course of testing this feature yesterday, Matt Flaschen spotted and fixed redundant module loading in TimedMediaHandler (see bug 55550). That's pretty cool, no?
Do remember that size != performance, though -- just because a module is small does not mean that it is performant. (The reverse is also true.) This tool also does not account for factors like gzip compression. So no burning developers at the stake, please :) But curious poking is definitely encouraged.
Thanks to Timo & Roan for helping this along.
Ori Livneh ori@wikimedia.org _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Thu, Oct 10, 2013 at 11:50 PM, Jon Robson jdlrobson@gmail.com wrote:
This is interesting Ori - thanks for sharing this / setting it up.
Thanks for checking it out!
Sorry to pick on this example in particular but I was surprised to see
so much code for the Universal Language selector (ULS) - especially as a single language speaker I don't ever use any of them - and I am thus being penalised.
אנחנו במיעוט הקטן בקרב האנושות של דוברי שפות אחרות מצטערים על אי הנוחות ומבטיחים ללמוד אנגלית בהקדם
FYI on mobile it doesn't work: I assume this just doesn't make use of
targets in RL to allow it to run on mobile?
As I understand, the 'targets' system was put in place to prevent mobile-inappropriate modules from being loaded by default. But this is not loaded by default; as you point out, there's an explicit mw.loader.using() call that specifies the module by name and causes to be retrieved on demand. For MobileFrontend to pretend that the module doesn't exist at that point seems like a design flaw of the targets system. I'm happy to specify mobile as a target for this module, but I think this is a point of friction between ResourceLoader and MFE that will continue to be a source of problems until it is resolved.
As I understand, the 'targets' system was put in place to prevent mobile-inappropriate modules from being loaded by default. But this is not loaded by default; as you point out, there's an explicit mw.loader.using() call that specifies the module by name and causes to be retrieved on demand. For MobileFrontend to pretend that the module doesn't exist at
that
point seems like a design flaw of the targets system. I'm happy to specify mobile as a target for this module, but I think this is a point of
friction
between ResourceLoader and MFE that will continue to be a source of problems until it is resolved.
Agreed on all points. Unfortunately it was the only real option at the time to ensure incompatible JavaScript/css wasn't added from other extensions / existing code / gadgets. The plan is for it to eventually die but inspect helps exactly with achieving that by highlighting what is loaded by default and weeding out what is suitable for mobile and what is not.
I do wonder if there is a way for targets to only apply to initially loaded modules and whether this is a good idea knowing some modules will be broken in this view.
_______________________________________________
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Sorry to pick on this example in particular but I was surprised to see
so much code for the Universal Language selector (ULS) - especially as a single language speaker I don't ever use any of them - and I am thus being penalised.
אנחנו במיעוט הקטן בקרב האנושות של דוברי שפות אחרות מצטערים על אי הנוחות ומבטיחים ללמוד אנגלית בהקדם
Hah. But I hope comedy aside my point holds. We should be all getting into the habit of loading things as and when needed rather than all at the beginning.
Sorry to pick on this example in particular but I was surprised to see
so much code for the Universal Language selector (ULS) - especially as a single language speaker I don't ever use any of them - and I am thus being penalised.
אנחנו במיעוט הקטן בקרב האנושות של דוברי שפות אחרות מצטערים על אי הנוחות ומבטיחים ללמוד אנגלית בהקדם
Hah. But I hope comedy aside my point holds. We should be all getting into the habit of loading things as and when needed rather than all at the beginning.
I know close to nothing about this, but I'm kind of interested in finding out. Would it be possible to $('little language toothed wheel thing').on('click', load something like jquery.uls.data)? That would already be 37.13KB.
Yup and it's as simple as ... $('little language toothed wheel thing').on('click', function() { mw.loader.using( 'modulename', function() { // do thing with modulename } ); } );
On Fri, Oct 11, 2013 at 1:28 PM, Dan Andreescu dandreescu@wikimedia.org wrote:
Sorry to pick on this example in particular but I was surprised to see
so much code for the Universal Language selector (ULS) - especially as a single language speaker I don't ever use any of them - and I am thus being penalised.
אנחנו במיעוט הקטן בקרב האנושות של דוברי שפות אחרות מצטערים על אי הנוחות ומבטיחים ללמוד אנגלית בהקדם
Hah. But I hope comedy aside my point holds. We should be all getting into the habit of loading things as and when needed rather than all at the beginning.
I know close to nothing about this, but I'm kind of interested in finding out. Would it be possible to $('little language toothed wheel thing').on('click', load something like jquery.uls.data)? That would already be 37.13KB. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Fri, Oct 11, 2013 at 1:28 PM, Dan Andreescu dandreescu@wikimedia.org wrote: I know close to nothing about this, but I'm kind of interested in finding out. Would it be possible to $('little language toothed wheel thing').on('click', load something like jquery.uls.data)? That would already be 37.13KB.
On Fri, Oct 11, 2013 at 5:01 PM, Jon Robson jdlrobson@gmail.com wrote:
Yup and it's as simple as ... $('little language toothed wheel thing').on('click', function() { mw.loader.using( 'modulename', function() { // do thing with modulename } ); } );
Dan, Jon -- why not submit a patch for these changes? Lazy-loading sounds like the right idea.
On Saturday, October 12, 2013, Dan Andreescu wrote:
I know close to nothing about this, but I'm kind of interested in finding out. Would it be possible to $('little language toothed wheel thing').on('click', load something like jquery.uls.data)? That would already be 37.13KB.
For the functions that are required only after a user interaction, like click ULS already lazy load scripts. One thing to note here is language selection one of the features of ULS. ULS avoids tofu(small boxes because of missing font) in the content presented through wiki pages, and that is an onload activity, without user interaction. That contributes the script size. But any help in reducing the script size is always welcome.
Thanks Santhosh
Santosh Thanks for clarifying - as stated before I wasn't picking on this in particular - it was just the easy observation to make from the results. I know very little about ULS but would be keen to understand a bit more about it. Are there any bugs open/wiki pages that I should be subscribed to to get more background and help out with us making this as slim as possible? Will be happy to help when I find some time.
On Fri, Oct 11, 2013 at 9:40 PM, Santhosh Thottingal santhosh.thottingal@gmail.com wrote:
On Saturday, October 12, 2013, Dan Andreescu wrote:
I know close to nothing about this, but I'm kind of interested in finding out. Would it be possible to $('little language toothed wheel thing').on('click', load something like jquery.uls.data)? That would already be 37.13KB.
For the functions that are required only after a user interaction, like click ULS already lazy load scripts. One thing to note here is language selection one of the features of ULS. ULS avoids tofu(small boxes because of missing font) in the content presented through wiki pages, and that is an onload activity, without user interaction. That contributes the script size. But any help in reducing the script size is always welcome.
Thanks Santhosh _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Thu, Oct 10, 2013 at 10:03 PM, Eran Rosenthal eranroz89@gmail.comwrote:
Nice feature, thanks!
- I tried to use it in ?debug=1 mode, and it seems to give 0 size to many
modules.
Yep -- already filed as https://bugzilla.wikimedia.org/show_bug.cgi?id=55553. I'll fix it.
2. It would be nice if it would also give details about dependent modules
(inclusive size vs exclusive size).
Yes, I agree. The only issue with adding that information is that it exceeds the amount of information that can be usefully represented in the debug console (at least in my opinion). I think the requirement for that should be implementing some table modal that floats above the page.
wikitech-l@lists.wikimedia.org