Hi,
Cold cache concerns aside (see the other email I just sent), I now have preliminary performance figures comparing Media Viewer to the status quo (File: page) in production. I'm still working with QA on getting our test merged and running automatically on cloudbees. The results I have were performed on a 2MB DSL connection in France, with nothing else running on the network.
Since we don't collect browser resolutions in our own stats (that I could find) I picked "average" and "large" desktop browser window sizes based on 3rd-party "internet-wide" statistics I could find online. These statistics differentiated desktop and mobile, so mobile's lower resolutions didn't affect the average. The "small" size was picked specifically to hit a bucket size identical to the File: page's image.
On an small browser window size (900x700), Media Viewer displays the image in a little less than 125% of the time it takes to display the image on the File: page
On an average browser window size (1366x768), Media Viewer displays the image in a little less than 125% of the time it takes to display the image on the File: page
On a large browser window size (1920x1080) I found the same result, but I suspect it might not be true, because my desktop wasn't big enough to accommodate that size in selenium's Firefox. I think we'll need to wait for cloudbees to run the tests headless for the real figure.
For the sake of argument, let's look at the difference in file size between the file page and the "average" browser size:
http://en.wikipedia.beta.wmflabs.org/wiki/File:Sunrise_over_fishing_boats_in...
- on the File: page, the image displayed is 800x600 (480,000 pixels) and weighs 52.7kb - on Media Viewer, at the "average" browser resolution, the image displayed is 1024x768 (786,432 pixels) and weighs 79.6kb
Therefore, the Media Viewer image has 63.8% more pixels on the screen and weighs 51% more.
But, this is only a consolation prize, because the small browser window size (900x700) which serves the same 800x600 image as the File: page still takes 20-25% longer, which seems to indicate that Media Viewer's overhead isn't due to the image size. Basically, if we made the File: page serve a 1024x768 image, it would certainly still beat Media Viewer.
We've already done multiple rounds of optimizing the performance of Media Viewer, but I'll investigate further to see if there's anything obvious that makes Media Viewer slower than opening the File: page.
In my opinion between 20 and 25% of overhead isn't a show-stopper for launch, considering that Media Viewer serves a bigger image in most situations, but it's worth giving optimizing one last try to see if we've missed anything. However, it could very well be that we can't do better and that the overhead is due to doing adding the image dynamically with JS instead of it being present in the pageload DOM of a relatively lightweight page.