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(a)wikimedia.org>
Reply-To: Wikimedia Commons Discussion List <commons-l(a)lists.wikimedia.org>
Date: Wednesday, September 25, 2013 8:25 AM
To: Wikimedia Commons Discussion List <commons-l(a)lists.wikimedia.org>
Cc: Ori Livneh <ori(a)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(a)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&…
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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/commons-l
_______________________________________________ Commons-l mailing list
Commons-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/commons-l