https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement/decoding
We could deploy this on ruwiki and see if it has an impact on survey responses. Speed up data gathering by purging the articles we're oversampling on.
https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement/decoding
We could deploy this on ruwiki and see if it has an impact on survey responses. Speed up data gathering by purging the articles we're oversampling on.
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)
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
Change 480950 had a related patch set uploaded (by Gilles; owner: Gilles):
[mediawiki/extensions/Cite@master] Fix test for img decoding="async"
Change 480952 had a related patch set uploaded (by Gilles; owner: Gilles):
[mediawiki/extensions/TimedMediaHandler@master] Fix test for img decoding="async"
Change 480928 merged by Aaron Schulz:
[mediawiki/core@master] Make thumbnail image decoding async
Change 480950 merged by Krinkle:
[mediawiki/extensions/Cite@master] Fix test for img decoding="async"
Change 480952 merged by jenkins-bot:
[mediawiki/extensions/TimedMediaHandler@master] Fix test for img decoding="async"
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
Change 484441 merged by jenkins-bot:
[mediawiki/extensions/ImageMap@master] Fix parser test by adding decoding="async" parameter
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.
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.