Ori Livneh has created a nice dashboard that regularly polls the Main Pages of a few of our projects to break down the amount of JavaScript (and other static assets) that's loaded for an anonymous pageview of the Main Page:
https://ganglia.wikimedia.org/latest/?r=week&cs=&ce=&tab=v&v...
Commons currently loads more than 1MB of JavaScript. This is too much, which negatively affects performance for our end users. Some of this is on WMF -- JS code we've deployed that we can optimize. But it would also be good to get community help with auditing site JS and gadgets that are loaded by default and that can be reduced in complexity, loaded only when needed, etc.
We'll aim to provide better debugging tools to the community in future but wanted to point this out in case anyone already wants to take a closer look.
Erik
Erik Moeller, 25/09/2013 07:19:
Ori Livneh has created a nice dashboard that regularly polls the Main Pages of a few of our projects to break down the amount of JavaScript (and other static assets) that's loaded for an anonymous pageview of the Main Page:
https://ganglia.wikimedia.org/latest/?r=week&cs=&ce=&tab=v&v...
Wonderful graphs!
Commons currently loads more than 1MB of JavaScript. This is too much, which negatively affects performance for our end users. Some of this is on WMF -- JS code we've deployed that we can optimize. But it would also be good to get community help with auditing site JS and gadgets that are loaded by default and that can be reduced in complexity, loaded only when needed, etc.
We'll aim to provide better debugging tools to the community in future but wanted to point this out in case anyone already wants to take a closer look.
Debugging and analysis tools are invaluable, however this is just an obvious consequence of the lack of basic functionalities for Commons in MediaWiki, which force the community to adopt local solutions via JavaScript. Surely, big improvements can be achieved even if we forget this for a moment, but to a degree. The WMF can also help by dedicating some resources to requests for help by the community in design questions about local gadgets (I believe there are a couple requests sitting in the design list) and to lending its JavaScript gurus for the optimisations.
Nemo
I'd recommend measuring some non-main-pages as well; that JavaScript payload seems to be reduced by about half if you load some other random page on Commons.
It looks like TimedMediaHandler is loading a lot to initialize a video that might never get played, for instance, while it never gets loaded on a page that doesn't include a video on it.
-- brion
On Tue, Sep 24, 2013 at 10:19 PM, Erik Moeller erik@wikimedia.org wrote:
Ori Livneh has created a nice dashboard that regularly polls the Main Pages of a few of our projects to break down the amount of JavaScript (and other static assets) that's loaded for an anonymous pageview of the Main Page:
https://ganglia.wikimedia.org/latest/?r=week&cs=&ce=&tab=v&v...
Commons currently loads more than 1MB of JavaScript. This is too much, which negatively affects performance for our end users. Some of this is on WMF -- JS code we've deployed that we can optimize. But it would also be good to get community help with auditing site JS and gadgets that are loaded by default and that can be reduced in complexity, loaded only when needed, etc.
We'll aim to provide better debugging tools to the community in future but wanted to point this out in case anyone already wants to take a closer look.
Erik
-- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
TMH, should only load a relatively small amour of code to support dynamic injecting of video for thumbnails that load the player on click and what not. But we can be sure to reduce this to an absolute minimum in the upcoming player v2 upgrade.
And clearly we should remove the 1k or so in the startup that is reloaded frequently. That startup code was focused on micro optimization against payload size, I.e not loading timed text library if in-page videos did not have timed text. But we now know / think its much better to have a slightly larger single payload for "video" and not have micro optimization logic being loaded all the time.
--michael
From: Brion Vibber bvibber@wikimedia.org Reply-To: Wikimedia Commons Discussion List commons-l@lists.wikimedia.org Date: Wednesday, September 25, 2013 8:25 AM To: Wikimedia Commons Discussion List commons-l@lists.wikimedia.org Cc: Ori Livneh ori@wikimedia.org Subject: Re: [Commons-l] JavaScript payload on Commons is twice English Wikipedia's
I'd recommend measuring some non-main-pages as well; that JavaScript payload seems to be reduced by about half if you load some other random page on Commons.
It looks like TimedMediaHandler is loading a lot to initialize a video that might never get played, for instance, while it never gets loaded on a page that doesn't include a video on it.
-- brion
On Tue, Sep 24, 2013 at 10:19 PM, Erik Moeller erik@wikimedia.org wrote:
Ori Livneh has created a nice dashboard that regularly polls the Main Pages of a few of our projects to break down the amount of JavaScript (and other static assets) that's loaded for an anonymous pageview of the Main Page:
https://ganglia.wikimedia.org/latest/?r=week&cs=&ce=&tab=v&v...
Commons currently loads more than 1MB of JavaScript. This is too much, which negatively affects performance for our end users. Some of this is on WMF -- JS code we've deployed that we can optimize. But it would also be good to get community help with auditing site JS and gadgets that are loaded by default and that can be reduced in complexity, loaded only when needed, etc.
We'll aim to provide better debugging tools to the community in future but wanted to point this out in case anyone already wants to take a closer look.
Erik
-- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
_______________________________________________ Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
I do not know much about JS, but I assume most of it is loaded by https://commons.wikimedia.org/wiki/MediaWiki:Common.js . Is there some other mechanism? How are default gadgets loaded? There is a lot of comments in Common.js, explaining purpose and authors/maintainers of each snippet of code, but even with that I often find it very hard to figure out which part of the interface is MediaWiki software and which is our local JS environment. I usually find out when I edit on other wikis and the tools or links I rely on are not there ("subpages" link comes to mind or link to template Transclusion count tool). I think it would be great if there was more documentation of the code and time frame for which it was intended. Many snippets seem to be patches for bugs with bug numbers in the documentation. We can probably check on status of those bugs.
Jarek T. User:jarekt
-----Original Message----- From: commons-l-bounces@lists.wikimedia.org [mailto:commons-l-bounces@lists.wikimedia.org] On Behalf Of Erik Moeller Sent: Wednesday, September 25, 2013 1:19 AM To: Wikimedia Commons Discussion List Cc: Ori Livneh Subject: [Commons-l] JavaScript payload on Commons is twice EnglishWikipedia's
Ori Livneh has created a nice dashboard that regularly polls the Main Pages of a few of our projects to break down the amount of JavaScript (and other static assets) that's loaded for an anonymous pageview of the Main Page:
https://ganglia.wikimedia.org/latest/?r=week&cs=&ce=&tab=v&v...
Commons currently loads more than 1MB of JavaScript. This is too much, which negatively affects performance for our end users. Some of this is on WMF -- JS code we've deployed that we can optimize. But it would also be good to get community help with auditing site JS and gadgets that are loaded by default and that can be reduced in complexity, loaded only when needed, etc.
We'll aim to provide better debugging tools to the community in future but wanted to point this out in case anyone already wants to take a closer look.
Erik
-- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
_______________________________________________ Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l