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&vn=Static+assets

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