Make it easier to override default loading optimizations

[joemcgill]

In [56037] (see #58853) a new set of functions were added to dynamically add loading optimization attributes, like loading="lazy" and fetchpriority="high" to images and iframes.

The main function responsible for this behavior is wp_get_loading_optimization_attributes(), which is called directly in several other places in core, like wp_img_tag_add_loading_optimization_attrs() and wp_iframe_tag_add_loading_attr(). However, there doesn't seem to be a straightforward way to disable or override this functionality globally.

Similar functions that are dynamically run on rendered HTML, like wp_img_tag_add_srcset_and_sizes_attr() and wp_img_tag_add_width_and_height_attr() have filters in place that allow you to disable that functionality if you want to remove it or implement your own processing via the wp_content_img_tag hook instead.

wp_img_tag_add_loading_optimization_attrs has a hook to filter the return value, but not until after wp_get_loading_optimization_attributes has been called, which
unfortunately produces side effects by calling wp_increase_content_media_count() or changing the value of wp_high_priority_element_flag().

Ideally, you could disable just the optimizations applied to rendered markup via a filter in wp_img_tag_add_loading_optimization_attrs() in case you needed to override just that functionality. However, wp_get_loading_optimization_attributes() should also be easier to override or turn off entirely so implementors could enhance core's defaults with their own optimization techniques.

[flixos90]

@joemcgill I just opened a somewhat related #58893, which is about adding a filter to wp_get_loading_optimization_attributes() for this purpose. I think adding a filter to that function makes the most sense as that is the low-level point / source of truth where the actual changes are controlled (rather than e.g. one of the wp_img_*() functions that call it, and are semantically tied to images).

So I think that ticket addresses part of the problems reported here. But I agree there is likely more to bring in order related to that, so I think this ticket is good to have this discussion. I definitely wouldn't consider it a duplicate, but rather overarching.

[joemcgill]

I saw that right after submitting mine 🤣. I think it makes sense to handle filtering wp_get_loading_optimization_attributes() via #58893, but let's leave this open to discuss the ability to override the optimizations added during wp_filter_content_tags() specifically.

[flixos90]

With [56347] committed, this effort is now unblocked. Please refer to the latest codebase for any changes to wp_get_loading_optimization_attributes().

[oglekler]

We need a patch and there is no time before Beta 1 to make and test it, so, I am moving this ticket into the 6.5 milestone. If someone produces the patch on the spot, it can be rescheduled back, but we need to be realistic.

[thekt12]

Newly introduced filter pre_wp_get_loading_optimization_attributes in #58893 is able to disable optimization logic completely without the side effects mentioned in the description.

Test code to disable optimization logic.

add_filter( 'pre_wp_get_loading_optimization_attributes', 'disable_wp_get_loading_optimization_attributes' );
function disable_wp_get_loading_optimization_attributes( $loading_attr ) {
	return array();
}

The same filter can be used to set any value for loading and fetchpriority enabling overriding of the default value.