This is a follow-up issue for #3752 (comment). Basically it seems not great that we keep running the will lazy load image steps, which access main-thread state, from an in-parallel context. I see two ways around this:

1. Observe the image with an intersection observer, so that the image intersection-checking steps are run as part of the update-the-rendering-steps, specifically as part of the run-the-update-intersection-observations-steps
   • We'd then need a way to react to "positive" intersections, which would entail resuming the suspended updating-the-image-data algorithm associated with the now-intersecting image
2. Create something new in the update-the-rendering-steps that checks if any lazy-loaded images associated with a document intersect with the veiwport, and if so, "resume" the suspended updating-the-image-data algorithm for the image
   • This seems to require some per-document(?) list of lazy-loaded images, which would be populated when the decision of load deferral is made in the updating-the-image-data steps
   • This list would be consulted in the update-the-rendering-steps, and intersecting images would be resumed, and removed from the list
   • We could generalize this by making the list of lazy-loaded images instead a list of lazy-loaded elements. Each item in the list could be a tuple <element, lazy condition, resumption steps>, and we could reuse this infrastructure for lazy-loaded iframes as well

Creating something new (the second proposal above) is probably preferable, but might have a very small compat impact. Chrome currently implements lazy-loaded images and iframes with an intersection observer under the hood. Since the "new" steps that we'd add to the update-the-rendering-steps would run at a different time than the run-the-update-intersection-observations-steps, I wonder if it would be possible to observe this (that is, observe the ordering between IO callbacks and image load resumption).

@annevk What do you think about (2) above?