There are a couple of distinct issues here:

1. the src isn't just the http(s) src as expected, and

2. the src is a data: URI, which is horribly inefficient

One could fix 2) by loading a blob instead of an ArrayBuffer and using createObjectURI()... but it would still be a URL that can't be copy-pasted usefully.

However I would probably recommend simply loading the image an an invisible <img> rather than an XHR; you won't get a chance at a full progress bar (just a delay then 'onload' or 'onerror') but the image will interact with things more or less as expected.

The reason for using XHR is that we want to access the headers so that we know whether the image was a cache hit on varnish, and if not, how is loading time split between thumbnail generation and real loading. (Anecdotally, slow rendering seems to be a big issue, with multiple-second image loading times, but we don't now how prevalent the problem is.) On production, this would only happen in an 1/1000 sample, not every request.

The original plan was to preload images via XHR, then set the src to the same URL as in the XHR request, but at least in current Chrome, that causes the image to be re-requested.

Change 114403 had a related patch set uploaded by Gergő Tisza:
Use cross-origin img attribute instead of data URI

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

We are abandoning data URIs, see commit message and https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/207 for details.

Change 114403 merged by jenkins-bot:
Use cross-origin img attribute instead of data URI

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