On Wed, Apr 9, 2014 at 3:03 AM, Gilles Dubuc gilles@wikimedia.org wrote:
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.
(...)
**the reason why we're not comparing figures with the File: page on a cold cache is that it's an unfair comparison: all of mediawiki's JS and CSS would be cold in that case, whereas for Media Viewer it's only Media Viewer's JS and CSS that is cold.*
On the other hand, a cold cache should happen infrequently (about once a week while MultiediaViewer is under active development, about once a month after that). Giving a bad first impression is unfortunate, but the user experience is not impacted that much beyond that, I think.
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.
Doing that means we could get rid of mmv.bootstrap entirely, increase the cold cache performance (chances are, the thumbnails on a given page will take longer to load than Media Viewer's JS and CSS) and simplify our code.
Any objections to doing this?
To clarify, this is the current state:
* mmv.head (~2K*) is top-loaded for every user on every page that contains images, to delay image thumbnail clicks until mmb.bootstrap is loaded * mmv.bootstrap (~35K with all dependencies) is bottom-loaded for every user on every page that contains images; it handles entry points (URL hash changes, image clicks) and loads the full application when the user requests it * the full application (around 500K) is only loaded when it is actually needed
This is what you propose:
* mmv.head is still top-loaded for everyone * everything else is bottom-loaded for everyone, all the time
Do I understand it right?
If so, I think we should consider this again when MediaViewer is enabled by default. Right now mmv.head and mmv.bootstrap is loaded for everyone, even if they did not opt in to the beta feature (or, on a pilot wiki, explicitly disabled the tool), so that we can handle URL hashes (and URLs shared by people who have MediaViewer enabled do not break for everyone else). This is not a big deal when we are just talking about a few kilobytes, but loading all of MultimediaViewer all the time for everyone, even if 99% will never use it, is not worth the performance win, IMO.
Once it is enabled for everyone, we should get some stats on what fraction of the userbase never uses it, and if it is not too large, then we can just load it for everyone (since it would be loaded for almost everyone with the current setup as well, just with a timing that's more inconvenient for the user).
* the sizes are unminified, ungzipped, which is not very useful, but that's what I had at hand.
(Sorry for the threadbreak. I thought I would CC this to wikitech-l since it would affect site performance in general, so I added more context to the subject, but then I didn't, and forgot to change it back.)
the sizes are unminified, ungzipped
Looking at the gzipped figures: - this change would add 104.8kb of minified gzipped JS+CSS, loaded async in the footer of pages that have thumbnails on them - a page like Lightbox_demo loads 95.6kb of external JS+CSS currently (there's a bunch of inline JS and CSS as well, though, which is hard to measure)
You're right, I didn't realize how bloated Media Viewer was, which makes my proposal a bad idea, since it would more than double the amount of JS+CSS loaded on articles. Our dependencies seem to play a large part: - jquery.color 0.5kb - jquery.colorUtil 1.2kb - jquery.fullscreen 0.7kb - jquery.scrollTo 1.4kb - jquery.tipsy 2.2kb - mediawiki.Uri 1.4kb - mediawiki.ui 0.8kb - mediawiki.ui.button 1.1kb - moment 11.5kb (!) - oojs 2.4kb - oojs-ui 40.1kb (!)
Totalling 63.3kb (60% of Media Viewer's weight)
This is yet another argument against OOjs UI, which has caused us so many problems. But now isn't the time to back out of it, we have to stick with it for the launch period. Moment is also questionable, considering how little functionality it provides (couldn't it be replaced by more server-side processing of dates?).
I guess an alternative is to start preloading Media Viewer's JS and CSS when the mouse cursor gets near thumbnails. What do you think of that? Doesn't solve the problem for touch screens, but the benefit for desktop would be tangible.
On Wed, Apr 9, 2014 at 11:02 PM, Gergo Tisza gtisza@wikimedia.org wrote:
(Sorry for the threadbreak. I thought I would CC this to wikitech-l since it would affect site performance in general, so I added more context to the subject, but then I didn't, and forgot to change it back.)
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
On Thu, Apr 10, 2014 at 1:42 AM, Gilles Dubuc gilles@wikimedia.org wrote:
This is yet another argument against OOjs UI, which has caused us so many problems. But now isn't the time to back out of it, we have to stick with it for the launch period.
On that note, UploadWizard is now apparently being rewritten to use OOjs UI. I think that could use more discussion, or it might end up being a wasted effort...
Moment is also questionable, considering how little functionality it
provides (couldn't it be replaced by more server-side processing of dates?).
Yeah, that's something we should do. Moment is huge and it is mostly about date arithmetics which we don't use at all.
I guess an alternative is to start preloading Media Viewer's JS and CSS when the mouse cursor gets near thumbnails. What do you think of that? Doesn't solve the problem for touch screens, but the benefit for desktop would be tangible.
Definitely worth trying. We really need to start tracking click-to-display times though, our current request performance oriented statistics tell us nothing about how much improvement such an approach would mean.
With the following applied:
https://gerrit.wikimedia.org/r/#/c/125402/ https://gerrit.wikimedia.org/r/#/c/125400/ https://gerrit.wikimedia.org/r/#/c/125383/ (this one isn't an improvement per-se, but it moves jQuery.scrollTo, which weighs 1.4kb, to the pageload, which lowers the amount loaded on click)
We're down to 42.1kb gzipped that has to be loaded when you click on a thumbnail with a cold browser cache.
We really need to start tracking click-to-display times though
mmv vs page file performance test tracked the cold cache experience, but yes, if I introduce the load-on-hover trick, the gain that most users will experience wouldn't be accounted for. I'll add a click-to-sharp-image metric when I write the hover preload code.
On Thu, Apr 10, 2014 at 8:30 PM, Gergo Tisza gtisza@wikimedia.org wrote:
On Thu, Apr 10, 2014 at 1:42 AM, Gilles Dubuc gilles@wikimedia.orgwrote:
This is yet another argument against OOjs UI, which has caused us so many problems. But now isn't the time to back out of it, we have to stick with it for the launch period.
On that note, UploadWizard is now apparently being rewritten to use OOjs UI. I think that could use more discussion, or it might end up being a wasted effort...
Moment is also questionable, considering how little functionality it
provides (couldn't it be replaced by more server-side processing of dates?).
Yeah, that's something we should do. Moment is huge and it is mostly about date arithmetics which we don't use at all.
I guess an alternative is to start preloading Media Viewer's JS and CSS when the mouse cursor gets near thumbnails. What do you think of that? Doesn't solve the problem for touch screens, but the benefit for desktop would be tangible.
Definitely worth trying. We really need to start tracking click-to-display times though, our current request performance oriented statistics tell us nothing about how much improvement such an approach would mean.
Multimedia mailing list Multimedia@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/multimedia
multimedia@lists.wikimedia.org