Fetch priority and lazy loading attributes not applying correctly in block themes

[spacedmonkey]

Images in block themes are not applying the image attributes correctly. While testing the following behaviours were noticed.

• Site logos in header of page, having loading="lazy".
• Image in header, not having fetch priority = high. Also not no lazy loading image.
• Image block hardcode into patterns not either loading and fetch priority attributes.

Steps to replicate.

• Activate TT2 theme.

This error has also been spotted in the following block themes.

• ​Frost
• ​neve-fse
• ​ollie

[spacedmonkey]

TT2, logo with lazy loading and header image with no attributes.

[spacedmonkey]

Frost theme - no lazily loading attributes.

[spacedmonkey]

Neve FSE theme- no lazy loading attribute.

[spacedmonkey]

For extra context, this ticket was first discussed on slack - ​https://wordpress.slack.com/archives/C02KGN5K076/p1688723359648689

[flixos90]

Thanks @spacedmonkey! Can you share a bit more context on the individual problems you saw? For example, for each theme that you tested:

• How are the images included that have missing or incorrect loading optimization attributes?
• Are the attributes not applied at all? Or are the images being lazy-loaded when they shouldn't? Or receiving fetchpriority="high" when they shouldn't?

I believe there are multiple underlying issues and different problems, so we need to inspect the individual scenarios more closely to figure those out.

Milestoning this for 6.4 for now, but we can adjust as needed once we know more. Also updating "Version" to 5.9 since only then block themes and the lazy-loading enhancements were introduced.

[spacedmonkey]

@flixos90 The screenshots, so the what is happening, so I would look at those.

I believe there are two issues here.

1. The same image is being processed a number of times, as different filters are applied at different times. I believe the same image might be being processed 2 or 4 times.
2. Hardcoded images in the templates do not have height and width attributes on the image blocks.

Here is an example of where there are ​hardcoded images in the TT2 theme. And another ​example from frost theme.

Trac ticket: https://core.trac.wordpress.org/ticket/58770

Trac ticket: https://core.trac.wordpress.org/ticket/58770

Code that run only single time:

static $themes_cache = null;

if ( null === $themes_cache ) {
	$stylesheet = get_stylesheet();
	$themes_cache = array(
		$stylesheet => get_stylesheet_directory(),
	);

	$template = get_template();
	if ( $stylesheet !== $template ) {
		$themes_cache[ $template ] = get_template_directory();
	}
}

cc. @felixarntz

[mukesh27]

Thanks @spacedmonkey and @thekt12 for the PRs. I left some feedback on both PRs for consideration.

@thekt12 your PR could potentially impact backward compatibility.

Caching that function call is not a good idea. It has a filter in it. That would result in the filter not running.

Thank you for the feedback. Is it possible to have distinct templates for various contexts, or will these modifications by the filters in place?

[flixos90]

After another review of this ticket, I am unsure about the next steps:

• I cannot replicate the issue reported about the Site Logo. Adding a Site Logo in TT2, I see it correctly receive fetchpriority="high" if it's configured to be large enough, and it doesn't receive loading="lazy". Potentially the report was made before WP 6.3 had implemented relevant fixes?
• Regarding the images hard-coded in the theme, I am unsure how we can fix the issue holistically, other than developer education. For Twenty Twenty-Two specifically, I opened a standalone issue to focus on only that, see #59256. The same thing happens in the other referenced themes, but fixing that in core would involve some sort of extra parsing pipeline of block templates, to then load the image file referenced to extract the dimensions and put them into the template - which would probably be an effort too large to achieve for 6.4 (we have less than 4 weeks at this point).

Let me know what you think @spacedmonkey. Realistically, I think we'll have to either close this issue (if we decide it's nothing to do for core) or punt it to "Future Release" (if we want to implement a central solution for core).

[spacedmonkey]

I agree with @flixos90 . Now that other fixes are in place, I am now seeing fp on site logos. I think we should follow up with #59256 and a dev note to educate developers.

I am closing this ticket as there is nothing to action here.