There will probably be techniques around this, but I think the JS hook would probably end up being the most straightforward and fault tolerant.

It sounds like you’re aware but for other readers: the core problem is that the DOM doesn’t know about the URL so it can’t fetch it until it first sees the replacing of the src attribute on the img element. Any trick you take to get that URL in the DOM before switching the src will reduce the flash but JS is the way only way to ensure the image is actually loaded before taking another action.

e.g

    var img=new Image();
    img.src=url;
    img.onload = callback; // callback places url in DOM.

I’m thinking off the top of my head here without testing but..

..a possible working could be having a list of images rather than one per item you want to display on the page. You always render the first image in the list normally. When a new images comes in, append to the list, and add an img element to the DOM (invisible but not display: none; otherwise it won’t download) without taking the original one away.

Then get the LiveComponent to tick after say 5s and remove the first element from the list, “promoting” your next image URL into the one which actually gets displayed. While the 5s window would give the image time to download it, it would not guarantee it like the JavaScript version would, obviously though you could play with the time window. You’d need CSS to ensure the images were laid on top of each other, and you could also add CSS transitions to transition between them, there are some examples of that here.

Writing that out I feels like I’ve invented frankenstein, I have no idea if that would actually work or be worth it.

Good luck, let us know.

Thanks for writing this up! It helps clarify my thinking. Funnily enough I’m actually using bitmap images inside SVG. So I can’t easily embed them inline, although I suppose I still could, but I’m not sure the larger payload size would be worth it, but I guess it depends on the size of the images (which I’m still figuring out).

I wonder if it would make sense to build support for this into Phoenix LiveView itself, since that could make this all transparent to the developer.