Given our existing understanding that pages are generally always able to render with text and layout before images appear (and hence have Low H-2 priority), I tried to find out more about what and how browsers behave by default.

I didn't get far, but the spec was the closest to a useful explanation I could find. (emphasis mine)

https://html.spec.whatwg.org/multipage/images.html#decoding-images

[..] Decoding [..] an image's media data into a bitmap form [..] can be slow relative to other processes involved in presenting content. [..]

Image decoding is said to be synchronous if it prevents presentation of other content until it is finished. Typically, this has an effect of atomically presenting the image and any other content at the same time. However, this presentation is delayed by the amount of time it takes to perform the decode.

Image decoding is said to be asynchronous if it does not prevent presentation of other content. This has an effect of presenting non-image content faster. However, the image content is missing on screen until the decode finishes. Once the decode is finished, the screen is updated with the image.

In both synchronous and asynchronous decoding modes, the final content is presented to screen after the same amount of time has elapsed. The main difference is whether the user agent presents non-image content ahead of presenting the final content.

It sounds like by default depending on some heuristics the browser might block text on image decoding, presumably to flush them both in the same paint. Imho this sounds like async decoding would be a win, as it would allow text or other things to get flushed in situations where it would have been blocked by image decoding.

Change 480928 had a related patch set uploaded (by Gilles; owner: Gilles):
[mediawiki/core@master] Make thumbnail image decoding async

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

Change 480950 had a related patch set uploaded (by Gilles; owner: Gilles):
[mediawiki/extensions/Cite@master] Fix test for img decoding="async"

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

Change 480952 had a related patch set uploaded (by Gilles; owner: Gilles):
[mediawiki/extensions/TimedMediaHandler@master] Fix test for img decoding="async"

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

Change 480928 merged by Aaron Schulz:
[mediawiki/core@master] Make thumbnail image decoding async

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

Change 480950 merged by Krinkle:
[mediawiki/extensions/Cite@master] Fix test for img decoding="async"

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

Change 480952 merged by jenkins-bot:
[mediawiki/extensions/TimedMediaHandler@master] Fix test for img decoding="async"

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

These sort of patches should be ported to Parsoid / at least have Parsoid ping'ed regarding them.

I thought about Parsoid, but first let's see if it's beneficial at all for merely reading articles rendered by MediaWiki on a web browser?

Change 484441 had a related patch set uploaded (by Thiemo Kreuz (WMDE); owner: Thiemo Kreuz (WMDE)):
[mediawiki/extensions/ImageMap@master] Fix parser test by adding decoding="async" parameter

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

Change 484441 merged by jenkins-bot:
[mediawiki/extensions/ImageMap@master] Fix parser test by adding decoding="async" parameter

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

Looking at synthetic and RUM data, it doesn't look like this had a visible effect on global metrics. This was an expected possible outcome, as it's possible that the browser's heuristics were already doing the right thing.

In T212124#4858668, @Gilles wrote:

I thought about Parsoid, but first let's see if it's beneficial at all for merely reading articles rendered by MediaWiki on a web browser?

The issue is that whenever you modify parserTests, you start failing parsoid tests until we sync those changes. Then we need to make a decision about whether to port the change to Parsoid or not. In this case, the PHP parser was changed, and apparently this change was deemed not beneficial, but it's not clear whether the change was ever backed out?

My point was that we should have a process for this so we can manage the changes and keep them in sync.

The change stayed. There was no measurable improvement, but no regression either. Semantically speaking it's the right thing to ask the browser to do for our images.