On Wed, Apr 9, 2014 at 3:03 AM, Gilles Dubuc <[email protected]> wrote:

> Hi,
>
> Since mediawiki.org finally moved to '21, I was able to run the
> performance tests against production again. We now have a figure for how
> bad the cold cache experience can be. On an average-sized browser window,
> the cold cache image load in media viewer takes around 200% of the time it
> takes for the image to appear on the File: page with a warm cache*. And it
> takes around 230% of the time for a large browser window. We're talking
> seconds of difference, that's a long time to wait.
>
> When we first built mmv.bootstrap (the on-demand loading of JS), we didn't
> have the click catcher (mmv.head). Now that we do, I think we can afford to
> sacrifice some user bandwidth and just load Media Viewer's JS with the
> async attribute (which means it wouldn't block page rendering). And
> mmv.head would take care of catching and replaying clicks that happened
> before Media Viewer's JS was loaded.
>

I'm not sure you even need mmv.head -- have you looked at mw.track? (<
https://doc.wikimedia.org/mediawiki-core/master/js/#!/api/mw-method-track>).
Specifically: "Data handlers are registered via mw.trackSubscribe, and
receive the full set of events that match their subscription, including
those that fired before the handler was bound."

You can also warm up the localStorage module cache by doing something like:

    $( window ).on( 'load', function () {
        setTimeout( function () {
            if ( mw.loader.store.enabled && mw.loader.store.get(
'mmv.moduleName' ) === false ) {
                mw.loader.using( 'mmv.moduleName', mw.loader.store.update );
            }

        } );
    } );

This will wait until the page has loaded and various load handlers have
yielded the UI thread before triggering a request for the module and saving
it in the localStorage cache.

In the final analysis if you can get the overall asset size down you may be
able to justify loading mmv unconditionally, discarding both optimization
strategies. You can always offset the impact (and then some) by fixing
TimedMediaHandler and mwEmbed to not add unnecessary startup modules, which
they currently do unconditionally on all page views.

But: before we get lost in the details, let me zoom out for a second and
simply applaud the whole team's approach (collecting data about user
experience and analyzing it rigorously) as being exemplary -- well done!


(Also CCing Nuria from Analytics -- she has a lot of relevant experience)
_______________________________________________
Multimedia mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/multimedia

Reply via email to