Could you share your views on why the File page mean (~3 seconds)
appears to take longer than the Media Viewer load (~2.6) on a cold
cache? I would have expected the reverse to be true, since Media Viewer
is loading larger images files, plus the thumbnails.
What the "versus" test sets out to compare is the following, measured visiting
mediawiki.org on a cloudbees instance:
Given an article where the page is fully loaded, thumbnails included, we measure the time it takes to do these two things:
- opening the file description page (File: page, usually on commons) and seeing the image fully displayed, as if the user command-clicked on the thumbnail to open the file description page in a new tab
- clicking on the file's thumbnail and having Media Viewer load the image and fully display it
This essentially compares the pre-Media Viewer status quo, to the Media Viewer experience. Now, the reason why I think the file description page is taking so long can be counter-intuitive, because when you open one yourself, it feels like the page appears instantaneously. However, what really happens, and we easily become blind to, is that the tab/window for that page is actually blank for a considerable amount of time before the content appears almost all at once. The cause for this blank time, which is probably experienced on a lot of our production wiki pages, is that we have too much synchronous javascript and css in the <head> of the document. Even if these are pulled from the browser cache (as is the case in this "versus" test), it takes time for the browser to load them up and interpret them in their entirety before moving on to rendering the page. Media Viewer doesn't suffer from this problem, because opening it doesn't induce a new pageload. In terms of performance, not inducing a new pageload is Media Viewer's biggest performance edge against the status quo of opening the file description page.
Now, there are known issues at play that make our production wikis bad with the amount of things in the head, one of which is on our team's plate: Timed Media Handler putting a ridiculous amount of stuff in the head. And our engineers focusing on general mediawiki performance are always actively looking to reduce the amount of synchronous js/css in the head. We should expect that if we collectively do our homework and improve the <head> situation, the file description page's performance should improve over time, and this "versus" test will actually let us see that.