WordPress 6.7 Auto-sizes Reducing Image Sizes

[dooperweb]

[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.

[junior]

Apologies if this is not allowed but I am noticing the same issue on my photography blog with hundreds of images.

[oglekler]

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

[joemcgill]

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?

[dooperweb]

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.

[nonobio]

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

[SirLouen]

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.

[youknowriad]

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/

[azaozz]

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".

[youknowriad]

@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?

[dooperweb]

My theme company(impreza) just released a fix, but it hasn't reached me yet. They probably created a filter for that. I just wanted to let you know.

Thank you

[leemon]

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.

[SirLouen]

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:

1. 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
2. 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 that width:fit-content is taking to render the image.
3. There is a ​Chrome known issue coming from Chrome 121 (February 2024) where, if HTML property size is set to auto (as it's implemented in the latest 6.7 update by default) in combination with loading=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

1. ​Screenshot of two images, width limited to 300px
2. ​Video showing the downscaling issue

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:

1. 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.

2. If this is happening to just a couple of images, simply add manually any of the two sizes, either width or height to your images

3. The most obvious one: remove width:fit-content from the CSS of your img 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.

[dooperweb]

ok thank you for your effort

[youknowriad]

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.

[joemcgill]

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;
}

[joemcgill]

Related: https://core.trac.wordpress.org/ticket/62345

Trac ticket:

[flixos90]

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.

@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"

[joemcgill]

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.

[flixos90]

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.

[azaozz]

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.

[joemcgill]

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.

[dooperweb]

@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%;
}

[azaozz]

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 the sizes="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.

[joemcgill]

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.

[flixos90]

@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.

[leemon]

I can confirm the issue is happening in a horizontal gallery I built with images using width: auto;

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 their width to either auto or fit-content will no longer appear in a smaller size than intended.

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

[mukesh27]

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?

[SirLouen]

Replying to mukesh27:

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?

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

As coordinated with @joemcgill via DM, this PR is now included in #7813, as they address the same problem.

[flixos90]

In 59415:

Media: Avoid images with sizes=auto to be displayed downsized in supporting browsers.

Based on the user agent stylesheet rules outlined in ​https://html.spec.whatwg.org/multipage/rendering.html#img-contain-size, images that have sizes=auto while applying width: auto or width: fit-content would be constrained to only 300px width.

This changeset overrides said user agent stylesheet rule with a much larger constraint, to avoid the problem.

Additionally, it introduces a filter wp_img_tag_add_auto_sizes which can be used to opt out of the functionality, as an additional measure.

Props joemcgill, flixos90, dooperweb, SirLouen, azaozz, mukesh27, apermo.
Fixes #62413.
See #61847, #62345.

Committed in https://core.trac.wordpress.org/changeset/59415

[flixos90]

This needs backport to the 6.7 branch.

[dougwollison]

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.

[mukesh27]

Replying to dougwollison:

So thecontain-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.

[desrosj]

Marking as needing a second committer sign off.

[desrosj]

#62469 was marked as a duplicate.

[joemcgill]

[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.

[desrosj]

Thanks everyone! I've tested as a fresh set of eyes and it looks confirmed [59415] is fixing the issue. Going to backport now.

[desrosj]

In 59435:

Media: Avoid images with sizes=auto to be displayed downsized in supporting browsers.

Based on the user agent stylesheet rules outlined in ​https://html.spec.whatwg.org/multipage/rendering.html#img-contain-size, images that have sizes=auto while applying width: auto or width: fit-content would be constrained to only 300px width.

This changeset overrides said user agent stylesheet rule with a much larger constraint, to avoid the problem.

Additionally, it introduces a filter wp_img_tag_add_auto_sizes which can be used to opt out of the functionality, as an additional measure.

Reviewed by desrosj, joemcgill.
Merges [59415] to the 6.7 branch.

Props joemcgill, flixos90, dooperweb, SirLouen, azaozz, mukesh27, apermo.
Fixes #62413.
See #61847, #62345.