Profile: https://share.firefox.dev/3ITxf4y

On https://www.voxchoirs.com/ there is some main thread jank where we're synchronously decoding a large WebP image.

This can be requested in some circumstances:
https://searchfox.org/mozilla-central/rev/71ff2d99628938eb74e983898c0fa2b1be6d5ef9/layout/generic/nsImageFrame.cpp#2350

Either the site requested sync decoding, or it swapped the image out with a different ratio.

Provided we have the metadata decoded, we could consider still dispatching in bulk using RenderBlocking priority:
https://searchfox.org/mozilla-central/rev/71ff2d99628938eb74e983898c0fa2b1be6d5ef9/xpcom/threads/EventQueue.h#29

And then waiting on a condition variable before we push the display list to make sure the compositor has access. It would require manually sharing the produced services as well, because we presumably can't spin/wait for the job that gets spawned during decoding:
https://searchfox.org/mozilla-central/rev/71ff2d99628938eb74e983898c0fa2b1be6d5ef9/gfx/layers/ipc/SharedSurfacesChild.cpp#259

It would require a bit more plumbing than that (to get the right external IDs, etc -- presumably we would need to allocate the external ID during the display list building, and assign it to the surface later....). As well as a new sync flag so that we can do the necessary syncing at the end.

The page itself unintentionally hits our "the page is setting src frequently, so we think it's an animation driven by setting img.src" detection

https://searchfox.org/mozilla-central/rev/71ff2d99628938eb74e983898c0fa2b1be6d5ef9/dom/base/nsImageLoadingContent.cpp#537

Js on the page sets the src to

https://static.wixstatic.com/...w_2196,h_858....jpeg
and then 400ms later to
https://static.wixstatic.com/...w_2196,h_852....jpeg
6 pixels shorter.

This is similar to what happens in bug 1786918.