Add support for the auto keyword for lazy-loaded images [#3587098]

Problem/Motivation

Mat Marquis published an article https://piccalil.li/blog/the-end-of-responsive-images/ about the broader availability of the auto keyword for the sizes attribute on the img element.

Before that, the sizes attribute required a lot of manual adjustment to align the sizes available in the srcset with the actual layout of a page/site to minimize the data transferred on every page load. above the fold that problem still applies, but for any lazy loaded image with the auto keyword applied, it is now up to the browser to decide which image best to load - the entire layout context is already available to them at that point.

Steps to reproduce

Proposed resolution

Add support for the auto keyword on lazy loaded images.

In regard to browser support, Blink, Gecko, and Webkit all have added support to it. In regard to older browser Mat Marquis writes:

Well, if you’re worried about browser support, don’t be — upon encountering the string “auto” at the start of a sizes attribute, any browser with support for it will say “figure it out myself; got it,” ditch the rest of the sizes attribute, and move on — browsers without support will throw the meaningless-to-them auto value out and continue on to the rest of attribute as usual.

So it is a progressive enhancement scenario with no need for any polyfill or the need to wait until the requirements listed in https://www.drupal.org/docs/getting-started/system-requirements/browser-... are full-filled.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Comment	File	Size	Author
#7	lazy.jpg	119.21 KB	rkoller
#7	setup.jpg	166.43 KB	rkoller

Issue fork drupal-3587098

Show commands

Start within a Git clone of the project using the version control instructions.

Add & fetch this issue fork’s repository

Or, if you do not have SSH keys set up on git.drupalcode.org:

Add & fetch this issue fork’s repository

3587098-add-support-for changes, plain diff MR !15627
Check out this branch for the first time

Check out existing branch, if you already have it locally

About issue forks

Comments

Comment #1

27 April 2026 at 13:29

rkoller created an issue. See original summary.

Comment #2

29 April 2026 at 21:00

bronzehedwick made their first commit to this issue’s fork.

Comment #3

30 April 2026 at 20:16

bronzehedwick opened merge request !15627

Comment #4

bronzehedwick

he/him

New York

commented 30 April 2026 at 20:19

Status:

Active

» Needs review

@rkoller I added an MR to add the auto keyword to sizes for any responsive image with an loading attribute of lazy.

The MR also normalizes spacing around the sizes items.

Open to any and all feedback!

Comment #5

smustgrave commented 30 April 2026 at 21:43

Status:	Needs review	» Needs work
Issue tags:		+Needs tests

Probably should have test coverage for new features

Comment #6

bronzehedwick

he/him

New York

commented 1 May 2026 at 17:41

Status:

Needs work

» Needs review

Makes sense @smustgrave! I pushed a fix that adds some unit and functional tests.

Comment #7

rkoller

he/him

German

Nürnberg, Germany

commented 19 May 2026 at 18:07

Status	File	Size
new	setup.jpg	166.43 KB
new	lazy.jpg	119.21 KB

Thank you for the MR @bronzehedwick and apologies for the belated comment, but figuring out the actual testing of the MR took me longer than I've hoped and anticipated. First I ran into the question which theme to pick and then into some odd results due to the fact that by default I start testing things in Safari first. I quickly outline the test setup.

I've installed a fresh Drupal site with the main branch using the demo_umami theme. Aside the default responsive image styles:

Large 3:2 2x (1536x1024)
Large 3:2 (768x512)
Medium 3:2 2x (1200x800)
Medium 3:2 (600x400)

I've also added

Small 3:2 2x (1000x666)
Small 3:2 (500x333)
Smallest 3:2 (200x133)
Smallest 3:2 2x (400x266)

I've only focused on the responsive image style the smaller images on the front page are assigned to. it also has to be noted that demo_umami uses 100vw for the sizes attribute, which might caused that way bigger images than expected were picked. For testing i took the following approach. I've opened browser windows in

Safari 26.5 (21624.2.5.11.4)
Safari Technology Preview Release 243 (WebKit 22625.1.15.19.1)
Firefox 151.0
Firefox Developer Edition 151.0b10 (aarch64)
Microsoft Edge Version 148.0.3967.54

Each of windows had, 960px in width so the multicolumn layout is being used, and resized the windows in height so that only the hero image is being displayed, and the rest of the images beneath the fold are getting lazy loaded.

the front page of umami just showing the hero image and the admin toolbar is collapsed

For every browser window I first deleted sites/default/files/styles, ran drush cr, reloaded the page in that browser window by clicking the reload button, documented the content of sites/default/files/styles, scrolled the page to the bottom, and then rechecked sites/default/files/styles. All browser windows were on a none retina screen when the tests were assessed:

Without the MR checked out:

Safari 26.5 (21624.2.5.11.4)

After load
small_3_2_2x_1000x666
borscht-with-pork-ribs-umami.jpg.avif
chili-sauce-umami.jpg.avif
crema-catalana-umami.jpg.avif
oatmeal-fruit-syrup-topping.jpg.avif
thai-green-curry-umami.jpg.avif

After scroll
no change

Safari Technology Preview Release 243 (WebKit 22625.1.15.19.1)

After scroll
no change

Firefox 151.0

After scroll
no change

Firefox Developer Edition 151.0b10 (aarch64)

After scroll
no change

Microsoft Edge Version 148.0.3967.54

After scroll
no change

With the MR checked out:

Safari 26.5 (21624.2.5.11.4)

After scroll
no change

Safari Technology Preview Release 243 (WebKit 22625.1.15.19.1)

After load
small_500x333
oatmeal-fruit-syrup-topping.jpg.avif

small_3_2_2x_1000x666
borscht-with-pork-ribs-umami.jpg.avif
chili-sauce-umami.jpg.avif
crema-catalana-umami.jpg.avif
thai-green-curry-umami.jpg.avif

After scroll
no change

Firefox 151.0

After load
small_500x333
oatmeal-fruit-syrup-topping.jpg.avif

smallest_3_2_2x_400x266
borscht-with-pork-ribs-umami.jpg.avif
chili-sauce-umami.jpg.avif
crema-catalana-umami.jpg.avif
thai-green-curry-umami.jpg.avif

After scroll
no change

Firefox Developer Edition 151.0b10 (aarch64)

After load
small_3_2_2x_1000x666
oatmeal-fruit-syrup-topping.jpg.avif

smallest_3_2_2x_400x266
borscht-with-pork-ribs-umami.jpg.avif
chili-sauce-umami.jpg.avif
crema-catalana-umami.jpg.avif
thai-green-curry-umami.jpg.avif

After scroll
no change

Microsoft Edge Version 148.0.3967.54

After load
small_500x333
oatmeal-fruit-syrup-topping.jpg.avif

smallest_3_2_2x_400x266
borscht-with-pork-ribs-umami.jpg.avif
chili-sauce-umami.jpg.avif
crema-catalana-umami.jpg.avif
thai-green-curry-umami.jpg.avif

After scroll
no change

So in summary it looks like the auto attribute is only available in the tech preview but not the stable version of safari so far based on the results from the tests above. While in the stable versions of the Developer Edition of Firefox and Edge browsers are doing things as expected with the auto attribute active. That rather large images are still loaded, might be due to the usage of 100vw for the sizes attribute in Umami; i dont wanted to start juggling with those sizes values, those are regularly breaking my brain. Not sure what others think after testing on their own, but for me that looks good.
The only odd thing, that images beneath the fold got loaded on page load and not lazy loaded on scroll in all four browsers i've tested in, even though the display settings have the lazy option activated for the image media item

the expanded image display widget for the responsive 3x2 view on the image media type showing that the lazy attribute is enabled

Comment #8

bronzehedwick

he/him

New York

commented 21 May 2026 at 00:54

Thanks for the detailed tests @rkoller! The results are really interesting. The lazy oddity seems to happen with or without this MR, correct? I was able to see images lazy loading correctly on a plain HTML site I whipped up to test. Maybe it's a separate issue with Umami?

Comment #9

rkoller

he/him

German

Nürnberg, Germany

commented 21 May 2026 at 02:56

yes, at least in my test in #7, no matter if the MR was checked out or the main branch, all images were loaded on page load already and none got actually lazy loaded.

i've just tested on the main branch with the standard profile within olivero. i've quickly created a content type with just a media image field (lazy loading active). there the lazy loading worked mostly. one post with an image was above the fold and three underneath, on page load the first two images already got loaded on scroll then the other two. but i have to test more in depth tomorrow or on the weekend.

Might have to do with the distance from viewport threshold referenced in the following article https://web.dev/articles/browser-level-image-lazy-loading#distance-from-... - but that was just the result of a brief search. not sure if that was the reason. but still odd that it hasnt worked in umami at all in my tests. will see tomorrow or on the weekend.

but in general i dont think that image not getting lazy loaded is related to this issue in any way. it might have to do with umami as you've suspected but with adding the auto attribute, otherwise lazy loading would have worked with the main branch checked out.

Comment #10

catch

he/him

English

commented 21 May 2026 at 08:37

Just to say the distance from viewport threshold on chrome is very big and varies by device type it can be thousands of pixels so a full screen height or more - usually means you need a very, very long page before images actually don't get loaded. Although the 'lazy' is I still think used to allow the browser to prioritise which images and assets to load even if it ends up loading everything.

Comment #11

bronzehedwick

he/him

New York

commented 21 May 2026 at 13:31

That makes sense @catch. I can see lazy images loaded much more quickly in Chrome than in Firefox or Safari.

Comment #12

rkoller

he/him

German

Nürnberg, Germany

commented 26 May 2026 at 17:55

thanks @catch. i have taken another look at the Chromium source that was linked in that web.dev article. those pixel values are indeed huge, with a connection speed set to offline the value is at 8000px .... so no wonder everything was loaded at once in most cases (i guess other browsers engines are not much different in that regard) ... aside that detail things look good from a manual testing perspective. I've also tested, the auto keyword is not getting added when loading is set to eager. so in case tests look good this issue looks good from my point of view.