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! :)
On Thu, Oct 10, 2013 at 10:03 PM, Eran Rosenthal <eranroz89(a)gmail.com> wrote:
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(a)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(a)wikimedia.org
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l 