-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ensure that first content image is not lazy-loaded in block themes either #3560
Ensure that first content image is not lazy-loaded in block themes either #3560
Conversation
The e2e test failing here is solely because I added one of the editor block files directly. In order to address that bit properly, I've opened WordPress/gutenberg#45534 to bring the same change to Gutenberg (and eventually port it to core). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
left one question about calling the_post
Update: The related Gutenberg PR has been merged (see WordPress/gutenberg#45534). Once that update is in WordPress core, I can update this PR to have the e2e test pass. |
src/wp-includes/media.php
Outdated
// Skip lazy-loading for the overall block template, as it is handled more granularly. | ||
if ( 'the_template' === $context ) { | ||
return false; | ||
} | ||
|
||
// Only elements within the main query loop have special handling. | ||
if ( is_admin() || ! in_the_loop() || ! is_main_query() ) { | ||
return 'lazy'; | ||
// Do not lazy-load images in the header block template part, as they are likely above the fold. | ||
$header_area = WP_TEMPLATE_PART_AREA_HEADER; | ||
if ( "the_template_part_{$header_area}" === $context ) { | ||
return false; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note for reviewers: These green lines are the only two things that are new in this function.
All remaining changes to this function look like more than they are due to GitHub: I wrapped the existing code in the condition for the_content
and the_post_thumbnail
to make the function logic easier to follow, and because of that GitHub makes it hard to decipher what's actually new here and what isn't. The logic for handling the_content
and the_post_thumbnail
is exactly the same as before.
@adamsilverstein This PR is now ready for a full review, since https://core.trac.wordpress.org/changeset/55079 is now committed to unblock this. I have updated this against latest The latest version of the PR has a more comprehensive solution than before, also covering block template parts that run through this logic as well. An easy win here was to also not lazy-load images by default that are in the |
Too bad I didn't spot the issue with the While this PR has to wait for that to be merged and backported, in terms of code this is already good to review. |
Update: This PR is simply waiting for WordPress/gutenberg#47203 to be backported to WordPress core, which will happen as part of the Gutenberg 15.1 RC backport. The pull request can already be reviewed as is and should be fully functional and ready for commit as soon as the backport has happened. Please ignore the e2e test failure since that failure is purely due to this PR modifying the one file that should come from Gutenberg instead. This also means the changes in the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nitpick: it would be nice to add @covers
tags to the test methods as this helps to calculate code coverage correctly.
The rest of the code looks good to me.
@adamsilverstein @mukeshpanchal27 @hellofromtonya This is now ready for a full review. Since the Gutenberg package updates have been backported, the remaining conflict is now resolved. It would be great if we could land this in time for the 6.2 Beta 2, as it would benefit from further testing on real websites using the Beta. |
@felixarntz The code changes appear to be correct to me, and I tested all of the test scenarios listed in the description, and they all worked properly. Great work! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @felixarntz! The functionality in the PR tests well. I followed the testing instructions for Twenty-Twenty Three, Twenty-Twenty Two and TT1 Blocks and all tests were successful.
Additionally, after test 3, I browsed to the single post page:
- Header: Not lazy loaded.
- Featured image: Not lazy loaded.
- First post image: Lazy loaded.
- Second post image: Lazy loaded.
- Footer image: Lazy loaded.
I've left some suggestions in the review regarding some additional tests and some minor docs additions.
A coverage report shows that line/branch coverage for wp_get_loading_attr_default()
is complete (note: not necessarily all applicable scenarios to protect BC going forward). As the function appears to be called twice during the execution of these integration tests, it took a little closer review to make sure each branch is hit correctly. 😅
* @covers ::wp_filter_content_tags | ||
* @covers ::wp_get_loading_attr_default | ||
*/ | ||
public function test_wp_filter_content_tags_does_not_lazy_load_first_featured_image_in_block_theme() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Query: Should this have "first_featured_image", or just "featured_image"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"first_featured_image" is correct, as other featured images further down in the page should still be lazy-loaded.
* @covers ::wp_filter_content_tags | ||
* @covers ::wp_get_loading_attr_default | ||
*/ | ||
public function test_wp_filter_content_tags_does_not_lazy_load_first_featured_image_in_block_theme() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In addition to testing:
- Doesn't have a featured image, and the first image is not lazy loaded.
- Has a featured image, which is not lazy loaded.
Should we also cover this?
- Has a featured image, and the first image afterwards is lazy loaded.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Has a featured image, and the first image afterwards is lazy loaded.
Hmm, this is already being tested here I think. The final assertion tests that the featured image is not lazy-loaded, while the first image afterwards (an in-content image) is lazy-loaded.
* @covers ::wp_filter_content_tags | ||
* @covers ::wp_get_loading_attr_default | ||
*/ | ||
public function test_wp_filter_content_tags_does_not_lazy_load_images_in_header() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we also add another test to ensure that images in a footer template part are always lazy loaded? I'm thinking in case something is later changed that accidentally excludes footer images from lazy loading.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@costdev This is already being tested by this method, the final assertion checks the entire template which includes both a header and footer template part, each with an image. Only the one in the header template part is expected to not be lazy-loaded, while the one in the footer should be.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 looks good to me, like the suggestion of one more unit test for footer if you have a chance.
@mukeshpanchal27 @costdev Thanks for the feedback and testing! I think I have addressed it all, please take a look. |
Some checks are failing! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the updates and responses @felixarntz! LGTM 👍
Looks like the test failures are related to the order of the is-layout-flow
, entry-content
, and wp-block-post-content
classes in the markup.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @felixarntz, The changes look good to me.
@robinwpdeveloper @costdev Test failures have been fixed. |
Committed in https://core.trac.wordpress.org/changeset/55318. |
post-content
block andpost-featured-image
block).wp_filter_content_tags()
runs over the entire template content after both the featured images and the post content images have already been processed once though. While the underlying problem for that is fixed in Avoid double-processing post content when parsing block template HTML #3549, this PR fixes theloading="lazy"
problem specifically in a decoupled manner, ensuring that by default the function always returnsfalse
when parsing the entire block template (via a newthe_block_template
context).post-featured-image
block would still receiveloading="lazy"
by default. The reason for that is that, in a block theme, the relevant logic runs outside of the loop - which strictly speaking is a backward-compatibility break in the first place. A fix for the exact same problem is already present in thepost-content
block, so this PR simply adds the same fix to thepost-featured-image
block.Trac ticket: https://core.trac.wordpress.org/ticket/56930
Test instructions
Any images can be used for the below tests.
core/image
blocks. When viewing them in the frontend, ensure that the first image does not have aloading="lazy"
attribute, while the second does have it.loading="lazy"
attribute.core/image
block anywhere in it. Then do the same for the "Footer" template part, insert acore/image
block anywhere in it. When viewing the frontend, ensure that the image you placed in the "Header" does not have aloading="lazy"
attribute, while the image you placed in the "Footer" does have it.This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.