On Wed, Apr 9, 2014 at 3:03 AM, Gilles Dubuc <gilles@wikimedia.org> 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)