Background image block support: optimize image output

[andrewserong]

Part of #54336

As raised in #54336 (comment) and #54336 (comment) it would be good to come up with a way to optimise the image output for the background image block support which is currently used by the Group block.

Ideas discussed thus far

• For performance, an img element within the Group block would be preferable as it allows both srcset and loading="lazy" so that images are lazy loaded, and only an image of an appropriate size.
• An img element however, can't implement all features supported by background-image, so for example repeating backgrounds would not be able to use the img element approach.
• If the support sometimes injects an img element and sometimes doesn't, this might make it hard for the support to work well with different themes and blocks that might opt in.
• If using an img element, how would this work with a background image support that is enabled in global styles? For example, if all Group or Post Content blocks are set to have a particular background image and we then go to update an individual block to use a different background image, how will these play together?
• image-set() was discussed, however it doesn't work with width descriptors so isn't really a viable alternative to the img element's srcset, and it doesn't allow lazy loading.
• Media queries could potentially be an option, however it involves injecting a style tag, and still wouldn't support lazy loading. However we can output things to a style tag via the style engine, so it might be a possibility.

Some requirements

• The solution needs to work for a generic block support that could be opt-in for any arbitrary block without breaking anything. I.e. how would it work for consumers if sometimes their block markup is augmented by this support in an unpredictable way?
• This block support is dynamically rendered, so any optimisation would also need to be dynamic without breaking themes
• The support will eventually include block-level global styles support, so whatever happens at the individual block level needs to be compatible with any background images set in global styles
• Ideally it should "just work" out of the box, rather than involve the user having to select a particular image size

Similar and related issues

• Cover Block: Add Background Image Size Selector #19223
• Cover Block with parallax effect does not use responsive friendly srcset attribute #35290

Other ideas

This issue is a good place for dropping ideas, thoughts, questions, concerns for how we might go about implementing image optimisation for the background image block support.

[ramonjd]

image-set() was discussed, however it #54336 (comment) so isn't really a viable alternative to the img element's srcset, and it doesn't allow lazy loading.

I'm looking at image-set() and I don't think we should write it off just yet. We can look at available images sizes and use a "next best guess" to determine if an image size gets a 1x or 2x etc. The browser will determine which one to use.

As for lazy loading, there's nothing native, yet. There are WordPress plugins that lazy load background images. That kind of thing usually increases the JS footprint though.

Or we could consider preloading the images somehow via JS or in HTML.

It's worth a small test at least to judge.

I'm leaning towards the opinion that it would be best not to use an <img> for background images, and rather try to find an acceptable way around performant delivery.

<img> would be convenient for available WordPress functionality, but it would limit the CSS properties available to the editor and, therefore, to theme users.