#62413 closed defect (bug) (fixed)
WordPress 6.7 Auto-sizes Reducing Image Sizes
Reported by: | dooperweb | Owned by: | joemcgill |
---|---|---|---|
Milestone: | 6.7.1 | Priority: | normal |
Severity: | normal | Version: | 6.7 |
Component: | Media | Keywords: | has-testing-info has-patch has-unit-tests fixed-major commit dev-reviewed |
Focuses: | performance | Cc: |
Description (last modified by )
[Edit: updated the ticket summary to more accurately reflect the cause of the issue]
Upon updating to WordPress 6.7, I noticed that images on my site appeared drastically smaller than intended. After investigating, I found that disabling the lazy load feature for each image (using the option in WPBakery) restored the images to their correct size.
It appears that WordPress 6.7 adds an auto lazy load attribute by default, which may be conflicting with existing lazy load features and causing images to render improperly.
Browsers Tested:
Issue occurs on: Chrome, Opera
Works as expected on: Firefox
I temporarily reverted to the previous version of WordPress to avoid having to manually disable lazy load on each individual image, as my site contains hundreds of images.
Change History (55)
This ticket was mentioned in Slack in #core-test by oglekler. View the logs.
3 weeks ago
#3
@
3 weeks ago
This ticket was discussed during the Test Team triage session. It is related to #62345.
We need steps to reproduce the issue, and we can possibly close this ticket as a duplicate and reopen the old one, depending on the issue. @sirlouen is working on this
#4
@
3 weeks ago
- Focuses performance added
- Keywords reporter-feedback added
- Owner set to joemcgill
- Status changed from new to reviewing
Thanks for the report, @dooperweb and for confirming @junior. It's likely that this is a result of the auto-sizes functionality that is applied to lazy-loaded images, and not lazy-loading itself.
Could either of you share an example of where you're seeing this behavior or more info about your theme that could be used to reproduce this issue?
This ticket was mentioned in Slack in #core by joemcgill. View the logs.
3 weeks ago
#7
@
3 weeks ago
Thank you for the prompt response, @joemcgill.
Template: Impreza
Page Builder: WPBakery
This is the preview on Chrome and Opera:
In the example, Image Element 2 displays the image at the proper size.
This issue only occurs with images where I use the image element in WPBakery. WPBakery has lazy loading enabled by default, which can be disabled individually for each item. When I disable lazy loading, the image displays correctly.
Below is the source code of the two elements:
Image Element 1 with lazy load enabled (default setting):
<div class="w-image-h"><img decoding="async" width="300" height="300" src="https://example.com/wp-content/uploads/2024/11/red-wordpress-icon-2048x2048-nw66awj8-300x300.png" class="attachment-medium size-medium" alt="" loading="lazy" srcset="https://example.com/wp-content/uploads/2024/11/red-wordpress-icon-2048x2048-nw66awj8-300x300.png 300w, https://example.com/wp-content/uploads/2024/11/red-wordpress-icon-2048x2048-nw66awj8-1024x1024.png 1024w, https://example.com/wp-content/uploads/2024/11/red-wordpress-icon-2048x2048-nw66awj8-150x150.png 150w, https://example.com/wp-content/uploads/2024/11/red-wordpress-icon-2048x2048-nw66awj8-96x96.png 96w, https://example.com/wp-content/uploads/2024/11/red-wordpress-icon-2048x2048-nw66awj8.png 2048w" sizes="auto, (max-width: 300px) 100vw, 300px"></div>
Image Element 2 with lazy load disabled in WPBakery:
<div class="w-image-h"><img fetchpriority="high" decoding="async" width="300" height="300" src="https://example.com/wp-content/uploads/2024/11/red-wordpress-icon-2048x2048-nw66awj8-300x300.png" class="attachment-medium size-medium" alt="" loading="eager" srcset="https://example.com/wp-content/uploads/2024/11/red-wordpress-icon-2048x2048-nw66awj8-300x300.png 300w, https://example.com/wp-content/uploads/2024/11/red-wordpress-icon-2048x2048-nw66awj8-1024x1024.png 1024w, https://example.com/wp-content/uploads/2024/11/red-wordpress-icon-2048x2048-nw66awj8-150x150.png 150w, https://example.com/wp-content/uploads/2024/11/red-wordpress-icon-2048x2048-nw66awj8-96x96.png 96w, https://example.com/wp-content/uploads/2024/11/red-wordpress-icon-2048x2048-nw66awj8.png 2048w" sizes="(max-width: 300px) 100vw, 300px"></div>
I have also seen similar complaints in a few forums, so I wanted to report it here.
Since my site has many images added this way, it would be too time-consuming to disable lazy load on each one individually. For now, I’ve downgraded to an older WordPress version to avoid this issue.
#8
@
3 weeks ago
Hi,
I think I have the same problem. After updating to WordPress 6.7, most of my images are smaller. I just restored WordPress version 6.6.2 and the images are displayed well again.
If I understood correctly, the next version 6.7.1 would solve the problem?
Will I see this update proposal in my WordPress dashboard?
Thanks
#9
@
3 weeks ago
- Keywords has-testing-info added; needs-patch removed
Reproduction Report
This report can't validate that the issue can be reproduced with the given information.
I've been trying to reproduce this problem first with WordPress "native environment" and only trying to observe first-hand on a clean WP how I could trigger the loading=lazy
on the images, and only after a significant amount of time I happen to discover this
<?php /** * Filters the threshold for how many of the first content media elements to not lazy-load. * * For these first content media elements, the `loading` attribute will be omitted. By default, this is the case * for only the very first content media element. * * @since 5.9.0 * @since 6.3.0 The default threshold was changed from 1 to 3. * * @param int $omit_threshold The number of media elements where the `loading` attribute will not be added. Default 3. */ $omit_threshold = apply_filters( 'wp_omit_loading_attr_threshold', 3 );
Here we can see that there is a hard-coded threshold where, for some reason and some versions ago (6.3), it was decided to move it from 1 to 3 images.
So if we happen to have 3 or fewer images loading, they won't have the loading=lazy
added by default
The convoluted part is that there is literally 0 info about this online, so I believe that it's good to know this first-place to analyze this issue 🤔
Environment
- OS: Windows 11
- Web stack: Nginx Docker (wordpress-developer env)
- WordPress: 6.8-alpha-59274-src
- Browser: Chrome 131.0.6778.69
- Theme: Twenty-Twenty
- Active Plugins:
- None
Reproduction Steps
STEP 1. Edit the theme CSS to show unrestricted width of the images on display. I've added a Child-Theme just for convenience.
For example, in Twenty-Twenty:
`
#site-content p, #site-content figure { max-width: 100%; }
STEP 2. Create a new Post.
STEP 3. Add some text and 4 high-resolution images (+1000px width) without any extra parameters
STEP 4. The 4th one will receive the loading=lazy
tag and is the one that we are expecting to be downscaled.
STEP 5. Observe if the last image is loading full resolution
First Results
- ❌ Error condition doesn't occur, last image loads adequately
Now that the default loading=lazy
is being loaded in the 4th image, I will add some extra steps for testing given the information provided by the reporter.
STEP 6. In functions.php
, we add this code to forcefully set-up loading=lazy
to all images, regardless of the built-in functionality of WordPress:
<?php function add_lazy_loading_to_content_images( $content ) { return preg_replace( '/<img(.*?)>/', '<img$1 loading="lazy">', $content ); } add_filter( 'the_content', 'add_lazy_loading_to_content_images' );
STEP 7. Observe if the last image is loading full resolution
Final Results
- ❌ Error condition doesn't occur, last image loads adequately again, issue can't be reproduced solely using WordPress, maybe there could be a conflicting issue with WP-Bakery code.
Additional Notes
I've also tried switching to the tags/6.7.0
to match the reporter's version, and the results are identical.
There is another closed similar issue #62345, which was fixed, but was failing due to another condition (Gutenberg adding width: fit-content
) so probably it's unrelated.
I've also tried limiting width
of the 4th image to different resolutions (1000, 800, 600), and they all display in the right size.
Since this WP-Bakery is a premium plugin, maybe reporter can ask from support to see how they are hooking to WordPress their loading=lazy
property and better observe where the issue could be coming from.
This ticket was mentioned in Slack in #core-test by sirlouen. View the logs.
3 weeks ago
This ticket was mentioned in Slack in #core-performance by youknowriad. View the logs.
3 weeks ago
#12
@
3 weeks ago
In case it helps, In this thread, some people are saying that the issue appears for images with links and is gone if the links are removed https://www.reddit.com/r/Wordpress/comments/1gr0ftk/wordpress_67_update_messed_up_my_websiteam_i_the/
#13
follow-up:
↓ 17
@
3 weeks ago
- Keywords needs-patch added
This seems related to #62345. Can reproduce it with images that have sizes=auto
and also have width: fit-content;
CSS applied to them. Seems to happen consistently in Chromium based browsers, works fine in Firefox.
Removing either auto
from the sizes
attribute, or width: fit-content;
fixes it. This sounds like a browser bug, and hopefully will be fixed upstream.
Seems a good fix for now may be to have a filter that plugins and themes can use to control adding of auto
to the sizes
attribute. The question is whether auto
should be present by default (as now) or let it be added by plugins and themes when they know there's no fit-content
on the images. That would probably depend on how common it is for images to have width: fit-content;
in the "wild".
#14
follow-up:
↓ 31
@
3 weeks ago
@azaozz it seems possible to disable the auto
attribute using this filter here https://core.trac.wordpress.org/ticket/61847#comment:23
Do you think we should offer a more straightforward filter while waiting for the upstream browser bug fix? Do we know if that browser bug is reported somewhere?
#16
@
3 weeks ago
I can confirm this issue in a custom horizontal gallery I built. It only happens when using Chrome or Edge. All images with loading="lazy" are affected, not just linked ones. Removing the A tag does nothing in my case. I had to remove the loading attribute from the images.
#17
in reply to:
↑ 13
@
3 weeks ago
- Component changed from General to Media
- Keywords close added; reporter-feedback needs-patch removed
- Resolution set to wontfix
- Severity changed from major to trivial
- Status changed from reviewing to closed
- Version set to trunk
Reproduction Report. Version 2
This second report validates that the issue can be reproduced, but no more action should be taken.
Environment
- OS: Windows 11
- Web stack: Nginx Docker (wordpress-developer env)
- WordPress: 6.8-alpha-59274-src
- Browser: Chrome 131.0.6778.69
- Theme: Twenty-Twenty
- Active Plugins:
- None
Actual Results
- ✅ Error condition occurs (reproduced).
Steps for Reproduction
STEP 1
I'm working with the Twenty-Twenty theme, so again, I have introduced an unrestricted width for the main content in the CSS. Most changes can be done in Them Customize
⇾Custom CSS
#site-content p, #site-content figure { max-width: 100%; }
STEP 2
Create a new Post.
Add a very good amount of text.
Add 4 high-resolution images (+1000px width images).
Don't modify any image parameters
STEP 3
The 4th one will receive the loading=lazy
tag and is the one that we are expecting to be downscaled.
STEP 4
Since the Gutenberg update:
https://github.com/WordPress/gutenberg/commit/e503a390e8cbfabb28049babc97489eb0c3827e1
fit:content
has been removed from Gutenberg as a selectable option. To reproduce this error, we need to add it on purpose.
According to the CSS specification, fit-content
is not meant to be used directly on HTML elements like img
but containers like figure
or div
.
If I set fit-content
into the figure
instead of the img
, it works flawlessly:
.entry-content figure { width: fit-content !important; }
To reproduce this issue, we need to forcefully add this img
level:
img { width: fit-content !important; }
✅ And the issue is reproduced successfully.
Additional Notes
My question was: Why is this exactly happening?
After some research, I have identified that this is a well-known issue for Chromium-based browsers:
First, we have to know this:
- Chrome doesn't apply lazy-loading to any image from 3000px from the viewport. This is why it's important to introduce a long text for reproduction
- Google introduced on September 16th
content-visibility
property by default in all Chromium-based browsers and added to the clients some default specifications, for example a fixed `width` of 300px. This is the exact number thatwidth:fit-content
is taking to render the image. - There is a Chrome known issue coming from Chrome 121 (February 2024) where, if HTML property
size
is set toauto
(as it's implemented in the latest 6.7 update by default) in combination withloading=lazy
it happens to downscale the image by default.
Here is my CodePen, with a brief example of this Chrome behavior
https://codepen.io/sirlouen/pen/YzmgByV
So in conclusion: this Chrome issue that downscale the images, in conjunction, with the new content-visibility
by default, that also limits the width
to 300px, it's generating this issue. You can better see this issue in the video attached.
Supplemental Artifacts
Conclusions & Potential Workarounds
For the WordPress part, no more actions should be taken. The idea of removing width:fit-content
from Gutenberg was more than enough.
Potential workarounds for the users affected by their themes/page builders are:
- If you are experiencing this problem, side wide, you should remove
size=auto
globally. You can use the proposed workaround by @flixos90, completely disabling this feature from your site.
Remember: This is not a bug, this is a feature implemented based on the HTML spec.
- If this is happening to just a couple of images, simply add manually any of the two sizes, either
width
orheight
to your images
- The most obvious one: remove
width:fit-content
from the CSS of yourimg
tags (although, this won't help with the downscaling)
So this issue can be closed, and this answer can be used as a future reference.
Don't hesitate to reopen if there are more scenarios where this issue is happening apart from with:fit-content
documented here.
#19
@
3 weeks ago
- Keywords close removed
- Resolution wontfix deleted
- Severity changed from trivial to major
- Status changed from closed to reopened
While it's true that this is a chromium bug, it doesn't mean that we shouldn't do anything about it in WordPress and keep the borden on the users. I think we should consider reverting the auto addition of "auto" until the chromium bug is fixed. Maybe it can be opt-in rather than opt-out.
This is still being discussed here https://wordpress.slack.com/archives/C07BTF54N68/p1731617952535259
I'm reopening the ticket.
#20
@
3 weeks ago
Thanks for the detailed testing report, @SirLouen.
I agree with @youknowriad that we should keep this open for now while we investigate how many sites are potentially affected by this change.
It's correct that this issue is only effecting Chromium browsers, but this is because only Chromium browsers currently support the sizes="auto"
HTML spec at this time. It's not necessarily due to a browser bug, but rather an intentional decision that size containment is a requirement for implementing auto-sizes. For details you can see this related issue or read this detailed explanation on why auto-sizes essentially requires image dimensions.
We're currently trying to understand how many sites are potentially affected by the combination of auto-sizes and overriding img styles in ways that cause the default UA stylesheet to kick in here:
img:is([sizes="auto" i], [sizes^="auto," i]) { contain: size !important; contain-intrinsic-size: 300px 150px; }
This ticket was mentioned in Slack in #core by desrosj. View the logs.
3 weeks ago
#23
@
3 weeks ago
- Description modified (diff)
- Summary changed from WordPress 6.7 Lazy Load Issue Reducing Image Sizes to WordPress 6.7 Auto-sizes Reducing Image Sizes
This ticket was mentioned in PR #7812 on WordPress/wordpress-develop by @joemcgill.
3 weeks ago
#25
- Keywords has-patch has-unit-tests added
Trac ticket:
#26
@
3 weeks ago
This is a duplicate of #62345 which provides additional context for the problem.
Per what is outlined in that ticket, it's worth clarifying that this is not a Chromium bug. The HTML specification itself outlines in https://html.spec.whatwg.org/multipage/rendering.html#img-contain-size the CSS rules that are provided by the user agent stylesheet, so putting width: content-fit
on those images violates the spec, so it would be an error in WordPress or the theme that uses it.
It's worth checking how widely this problem comes up, if we're able to gather any metrics on this, and then deciding on the next steps. But a revert of the entire feature should only be considered if it's widespread and no reasonable alternatives exist. Since it's not a Chromium bug, the browser behavior in that regard won't change. On the other hand, it is still unclear to me why width: fit-content
is needed.
@joemcgill commented on PR #7812:
3 weeks ago
#27
@felixarntz:
WordPress should never add loading="lazy" in the first place if an image doesn't have both width and height attributes.
That's true, but our tests and the wp_img_tag_add_auto_sizes()
function itself doesn't ensure that the img
has a width attribute before adding sizes="auto"
#28
@
3 weeks ago
While investigating this, it occurred to me that wp_img_tag_add_auto_sizes()
doesn't explicitly confirm that a width
attribute is present before applying auto-sizes. That said, Core won't add lazy-loading in this case, so normally auto-sizes still won't apply. Even so, I've added a PR that is mostly a hardening measure to ensure this can't occur.
#29
follow-up:
↓ 34
@
3 weeks ago
- Keywords needs-refresh added
- Severity changed from major to normal
I just implemented and ran a query for the HTTP Archive dataset to assess how widespread the resulting problem is: https://github.com/GoogleChromeLabs/wpp-research/pull/163
This query considers the image's relevant CSS as it uses the computed style width from the browser for its results.
It is safe to say that the problem is not widespread: Only 0.09% of WordPress URLs have images using width: fit-content
.
As such, a revert of the feature would not be appropriate. Themes that set width: fit-content
unconditionally on images should be encouraged to fix this. For the small portion of WordPress sites affected by this problem, I think a proper solution would be to introduce an easy-to-use filter that allows to disable the sizes="auto"
feature specifically. This would be a better solution for those sites than to also disable lazy-loading entirely.
This ticket was mentioned in Slack in #core-performance by flixos90. View the logs.
3 weeks ago
#31
in reply to:
↑ 14
@
3 weeks ago
Replying to youknowriad:
@azaozz it seems possible to disable the
auto
attribute using this filter here https://core.trac.wordpress.org/ticket/61847#comment:23
Right, I actually used very similar code for testing.
Do you think we should offer a more straightforward filter
Frankly at first I thought another filter may be overdoing it. But while chatting about this with @joemcgill yesterday changed my mind and now thinking it may be preferable to have a more granular/straightforward way to control or disable adding of auto
to sizes
attribute, or the whole attribute value.
#32
@
3 weeks ago
Thanks for gathering the data, @flixos90. Assuming the majority of cases that have been reported are due to this CSS, related issue, I agree that a revert would be not be appropriate.
@dooperweb, I can see from your WPBakery example that the plugin uses a custom lazy-loading implementation and the image markup also includes a width
attribute, so a similar CSS issue is likely to be the cause of the problem. Can you confirm whether the image has some CSS affecting the width
of the images?
@azaozz I'll work on a PR to add a simpler filter for this.
#33
@
3 weeks ago
@joemcgill There is no specific CSS applied to the image. Only global CSS rules are in effect, as shown below:
img { height: auto; max-width: 100%; }
#34
in reply to:
↑ 29
@
3 weeks ago
Replying to flixos90:
As such, a revert of the feature would not be appropriate. Themes that set
width: fit-content
unconditionally on images should be encouraged to fix this. For the small portion of WordPress sites affected by this problem, I think a proper solution would be to introduce an easy-to-use filter that allows to disable thesizes="auto"
feature specifically. This would be a better solution for those sites than to also disable lazy-loading entirely.
Sounds good, +1.
@azaozz I'll work on a PR to add a simpler filter for this.
Great! Wondering if a filter for the whole attribute value of sizes
would be better here? Seems it would make it trivial to add/remove/control auto
, and may be more useful in the long run.
#35
@
3 weeks ago
I've updated PR #7812 to include a new filter to disable auto-sizes more easily. In doing so, I'm also proposing to consolidate all of the logic responsible for this feature in the same function to improve maintainability.
#36
@
3 weeks ago
@joemcgill pointed out to me that the problem can also occur for sites that use width: auto
for images in CSS.
As such, I queried HTTP Archive for that and unfortunately (though as I would expect) the usage of that is not a trivial amount. Between 15-20% of WordPress sites have at least one image with that CSS rule applied. The overall % of images across WordPress sites is between 7-9%, so that means by far not every image is affected, but some images. In any case, these percentages are a lot higher than those for width: fit-content
, so for that I don't think a filter to opt out is sufficient (though that's still worth exploring).
That said, a revert still does not seem right if we can come up with a fix, because >80% of WordPress sites still benefit from this feature without any side effects.
A good solution we discussed via DM would be to override the user agent stylesheet rule for contain-intrinsic-size
. By setting those constraints to much larger values, we would avoid the visual problem for any of the sites. Needless to say, it should still be discouraged to use width: auto
and width: fit-content
in favor of better ways to constrain images, but for the themes that use that today this workaround would address the problems, without negatively impacting all the sites that aren't affected by the problem.
Specifically, we could include this in wp_head
:
img:is([sizes="auto" i], [sizes^="auto," i]) { contain-intrinsic-size: 3000px 1500px; }
These values are 10x the default and they are large enough that almost no images (probably <1% of images) would still be downsized.
#37
@
3 weeks ago
I can confirm the issue is happening in a horizontal gallery I built with images using width: auto;
This ticket was mentioned in PR #7813 on WordPress/wordpress-develop by @flixos90.
3 weeks ago
#38
- Keywords needs-refresh removed
This PR implements what's described in https://core.trac.wordpress.org/ticket/62413#comment:36.
With this fix:
- Images that have
sizes=auto
(by default all lazy-loaded images in WordPress) _and_ are affected by a CSS rule that sets theirwidth
to eitherauto
orfit-content
will no longer appear in a smaller size than intended.
Trac ticket: https://core.trac.wordpress.org/ticket/62413
#39
follow-up:
↓ 40
@
3 weeks ago
Just show that Google chrome adds CSS from browser side. Checked in Version 130.0.6723.117
and 131.0.6778.70
version.
img:is([sizes="auto" i], [sizes^="auto," i]) { contain: size !important; contain-intrinsic-size: 300px 150px; }
Do we still needs to add anything from our side?
#40
in reply to:
↑ 39
@
3 weeks ago
Replying to mukesh27:
Just show that Google chrome adds CSS from browser side. Checked in
Version 130.0.6723.117
and131.0.6778.70
version.
img:is([sizes="auto" i], [sizes^="auto," i]) { contain: size !important; contain-intrinsic-size: 300px 150px; }Do we still needs to add anything from our side?
If you are having problems with this, soon a new patch will be released.
Simply by adding
<?php add_filter('wp_img_tag_add_auto_sizes', '__return_false');
It will solve the issue.
It's scheduled for next update 6.7.1
@flixos90 commented on PR #7812:
2 weeks ago
#41
As coordinated with @joemcgill via DM, this PR is now included in #7813, as they address the same problem.
@flixos90 commented on PR #7813:
2 weeks ago
#43
Committed in https://core.trac.wordpress.org/changeset/59415
#44
@
2 weeks ago
- Keywords fixed-major added
- Resolution fixed deleted
- Status changed from closed to reopened
This needs backport to the 6.7 branch.
#45
follow-up:
↓ 46
@
2 weeks ago
So thecontain-intrinsic-size
fix by @flixos90 seems to cause an opposite issue, with my use case anyway; images are now stretched too tall.
It's admittedly a weird edge case; I technically have aspect-ratio:auto explicitly set on all images (because custom properties), which causes height: auto
to evaluate to whatever the contain-intrinsic-size
height is.
https://codepen.io/dougwollison/pen/vYoPYwE
Given it's a chromium bug (https://issues.chromium.org/issues/378870236), I'm not sure theres any other way to fix this with CSS, so personally I find the wp_img_tag_add_auto_sizes
solution to suffice.
#46
in reply to:
↑ 45
@
2 weeks ago
Replying to dougwollison:
So the
contain-intrinsic-size
fix by @flixos90 seems to cause an opposite issue, with my use case anyway; images are now stretched too tall.
Felix added CSS that aligns with the updates introduced in Google Chrome.
Next, we should check how many sites are using aspect-ratio: auto
CSS. I assume the number isn’t significant, but this is something we could look into further.
#47
@
2 weeks ago
- Keywords dev-feedback commit added
Marking as needing a second committer sign off.
This ticket was mentioned in Slack in #core by desrosj. View the logs.
2 weeks ago
This ticket was mentioned in Slack in #core by desrosj. View the logs.
2 weeks ago
#51
@
2 weeks ago
- Keywords dev-reviewed added; dev-feedback removed
[59415] looks good to me for back-porting. I've tested trunk successfully.
@dougwollison's use-case is indeed a possible side effect of this change. I think the inclusion of the new wp_img_tag_add_auto_sizes
filter to disable this functionality is a reasonable off-ramp for folks with conflicting custom implementations.
#52
@
2 weeks ago
Thanks everyone! I've tested as a fresh set of eyes and it looks confirmed [59415] is fixing the issue. Going to backport now.
Apologies if this is not allowed but I am noticing the same issue on my photography blog with hundreds of images.