window.onload should not have been be used (that waits for images to download, iframes to load etc.). At dom-ready all the information you should need is available. Trivial switch to make in the event binding of the initialisation code.

To get a better response out of the page, ensure the initialisation code is dependency free and small in size, and then load it from the position => top queue. This queue blocks the browser from beginning to parse the HTML body while the script downloads and executes synchronously. This position can be used to do quick checking against the Location object or browser environment. Bsed on that, asynchronously enqueue loading of the main code (similar to what the current onload handler does I imagine).

Sorry, I got that wrong, we do use domready. The problem is that by that point the browser has queued all thumbnails on the page, and anything else MediaViewer tries to load is queued after them. On something like an image category page that's several seconds of delay (tens of seconds on a slower connection).

The current default behavior is loading a small initalization script at the top (which is mostly about delaying the handling of image clicks until the handler has loaded), loading a larger initialization script at the bottom, and loading the rest of the code on demand (click, long hover over an image, hash change). This works well in the general case and has very little overhead, but when the user visits, say, [[Main_Page#mediaviewer/File:View_of_the_Fort_of_the_Natchez.jpg]], then waiting for the page to load before fully loading MediaViewer is exactly the wrong strategy, since the user is primarily interested in the lightbox view of [[File:View_of_the_Fort_of_the_Natchez.jpg]] and not in the main page; whatever is needed to display that view should be loaded before the page itself loads. So I think top-loading everything, which is generally a very bad practice, would be justified in that specific case.

Mass-removing the Multimedia tag from MediaViewer tasks, as this is now being worked on by the Reading department, not Editing's Multimedia team.