I suspect this may be a regression, as I'd like to think I would have noticed this earlier had it always been that way (either in any past week, or during the perf review for launch). However, it's possible that we missed this somehow?

The whole page was like this for months, if not since the launch. It also prevents from leaving the page with ‘Are you sure you want to lose changes?’ dialog sometimes. Good that someone finally filed a task (as it would’ve been out of my wheelhouse to explain it).

@CBogen do you set the priorities ?

This affects performance, downgrades our pagerank score at Google significantly and annoys users. This seems an easily fixable problem with addModuleStyles reserving the appropriate space before infusing the page with the JS widgets. More importantly... it never should have been +2'ed like this, especially when it's present in the anonymous version of pages....

We block dozens of patches for problems like this, and thus, this should have been picked up and prioritized over any sort of feature development in my opinion. When we don't, that is how we end up with technical debt.

This rendering is annoying, and thank you for this bug ticket. We have a slow rendering process and it’s our plan to have some better options available for teams who need to render interactive JS elements on the server. Attempts to recreate the bug confirm that it’s only on some browsers and with files, not images. So, I’m keeping the ticket in our backlog to see if we can fix it as we make overall improvements, and will weigh it against other bug tickets to see about some tweaks, which aren't a long-term solution.

I respectfully disagree that this is not important for reasons mentioned by TheDJ. And fixing this shouldn't be hard. I am curios to know what would be the overall improvements would be.

Note that WikibaseMediaInfo renders server-side already. The SDE team uses OOUI-php for the file description page, which has rendered server-side for many years. The SDE team also developed this feature from the start in a way that addresses differences between the basic version and interactive JS layer on top of that (e.g. clickable tabs vs heading). They solved this by showing the tabs only for .client-js mode (as specified server-side through CSS), and the headings only for .client-nojs. This option has been in the platofrm for a decade or so and is being correctly and effectively applied here to avoid visible defects with those.

The problem is merely that there is JavaScript code separate from the rendering of widgets, that is accidentally causing these (minor but very visible) defects. There seems to be initialisation code that unintentionally hides the widget, and then re-inserting it not until some time later. And there seems to be a duplication of styles where multiple conflicting versions of the same styles are loaded at different times, each styling the tabs in a slightly different manner and with different paddings between rows.

These three related bugs can and likely would exist even if the code were rewritten in a different server-side rendered format.

I estimate the following minor changes would remedy these bugs:

• remove this duplication in styles and bring it back to a single base stylesheet,
• to avoid flashing the statements widget by ensuring it remains initially "hidden", much like the headings are already,
• fix the bug in the code that is currently instructing to remove and later then re-insert the same widget.

Note these suggestions are not performance advice. I'm just trying to help explain the issue. If the team addresses this differently instead, that'd be just as good if not better :)

Change #1112365 had a related patch set uploaded (by Dylsss; author: Dylsss):

[mediawiki/extensions/WikibaseMediaInfo@master] Reduce content flashes and repaints

https://gerrit.wikimedia.org/r/1112365