You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 24, 2024. It is now read-only.
I wanted to bring your attention to a potential performance problem with certain aspects of the theme, as it is currently implemented.
Background
When an image block is added in the editor, the HTML that is generated is something along the lines of:
<figureclass="wp-block-image size-full"><imgsrc="[URL GOES HERE]" alt="" class="[CLASSES GO HERE]"/></figure>
This is a very simple image tag that is missing some important best practices in the form of added attributes:
A srcset with multiple sources for the browser to choose from, to ensure that bytes aren't wasted downloading excessively large variants.
A loading tag with the lazy value for images which we expect to be below the fold or otherwise not the centre of attention, so that the browser can prioritise downloading important resources first.
A width and height, so that together with the CSS, the browser can calculate and reserve the space for the image ahead of time, in order to avoid layout shifts.
For content (attachment) images, this is all added by WordPress when serving. However, that's not the case for theme images, which are served verbatim, without any of the aforementioned attributes.
The issue
Currently, the theme defines several "recipes" (can't think of a better generic name), such as patterns, that make use of theme images. Whenever these patterns get used, their images will fail the best practices above. This means potentially introducing performance issues (delaying page load), as well as user experience issues (layout shifts).
Furthermore, unless the user replaces these images with attachment images, they have no way of getting around the issues; the site editor offers no mechanism for fixing these problems, since it hasn't been designed to. The layer that is supposed to handle these problems isn't the editor, but rather WordPress, during serving, and it is unable to do so with theme images.
Potential solutions
I'm not entirely sure what the best way of going about fixing this issue might be.
Perhaps instead of using theme images in patterns and other "recipes", we could instead use some form of placeholder?
If that's not an option, perhaps we should consult with some site editor experts to explore options as block themes become both more popular and more complex.
Thanks for taking a look!
The text was updated successfully, but these errors were encountered:
Thanks for opening this issue! I'm concerned that this is an issue that not only applies to TT4 and any other block theme out there, but also to the entirety of the block pattern directory, so we definitely should find a global solution for this
Hey folks! 👋
I wanted to bring your attention to a potential performance problem with certain aspects of the theme, as it is currently implemented.
Background
When an image block is added in the editor, the HTML that is generated is something along the lines of:
This is a very simple image tag that is missing some important best practices in the form of added attributes:
srcset
with multiple sources for the browser to choose from, to ensure that bytes aren't wasted downloading excessively large variants.loading
tag with thelazy
value for images which we expect to be below the fold or otherwise not the centre of attention, so that the browser can prioritise downloading important resources first.width
andheight
, so that together with the CSS, the browser can calculate and reserve the space for the image ahead of time, in order to avoid layout shifts.For content (attachment) images, this is all added by WordPress when serving. However, that's not the case for theme images, which are served verbatim, without any of the aforementioned attributes.
The issue
Currently, the theme defines several "recipes" (can't think of a better generic name), such as patterns, that make use of theme images. Whenever these patterns get used, their images will fail the best practices above. This means potentially introducing performance issues (delaying page load), as well as user experience issues (layout shifts).
Furthermore, unless the user replaces these images with attachment images, they have no way of getting around the issues; the site editor offers no mechanism for fixing these problems, since it hasn't been designed to. The layer that is supposed to handle these problems isn't the editor, but rather WordPress, during serving, and it is unable to do so with theme images.
Potential solutions
I'm not entirely sure what the best way of going about fixing this issue might be.
Perhaps instead of using theme images in patterns and other "recipes", we could instead use some form of placeholder?
If that's not an option, perhaps we should consult with some site editor experts to explore options as block themes become both more popular and more complex.
Thanks for taking a look!
The text was updated successfully, but these errors were encountered: