srcset was disabled on mobile web due to bandwidth concerns in T119797: Serve low-res images by default to users on slow or metered mobile connections. It might be time to re-evaluate that decision, especially considering the increase in prevalence of high-dpi mobile devices.

See also T69709 and T69695
In short, the thumbnail landscape is pretty complicated. That said this is not really a mobile-specific problem. This is also a problem on desktop.

I remember when this change was done. One of the reasons was that we do not want to download extra bloat for users that could be paying per byte. This was also done before lazy loading of images was introduced. You can check sites like https://whatdoesmysitecost.com/test/211019_AiDc8D_c92a3e61768f4377bada46b18e334388#gniCost to see estimated cost. But with lazy loading it doesn't give a correct result. @Jdlrobson do you know if we have any statistics on how many images that are actually loaded per page load/total images that could be loaded?

Using the Network Information API is Android only and will not work on first page load. When the HTML page is downloaded, the pre load scanner in the browser scans the HTML for JS/CSS/images to start to download (to utilise the network) but using the network API, we need to change the HTML when the browser execute the JavaScript and that is something we want to avoid, since it could potentially make the browser download multiple versions of the same images, so the first view would give worse performance/size for the user. You can read more about the pre load scanner here.

I think we are missing something in our infrastructure/setup to make surfing Wikipedia on slow networks/cpu better where we would serve images/JS/CSS differently. If you haven't read how LinkedIn do it, its an interesting read. I'm thinking a larger initiative to fix that would be great.

In T293303#7429572, @Jdlrobson wrote:

In short, the thumbnail landscape is pretty complicated. That said this is not really a mobile-specific problem. This is also a problem on desktop.

I believe this task is about "blurry thumbnails on hi-res devices". This is a side-effect of disabling srcset, which we decided to for mobile, is controlled by wgMFStripResponsiveImages, and is applied by MobileFrontend for mobile and only on mobile.

If this problem is not mobile-specific, then what do you mean by "this problem", and in what way does it affect desktop?

wgMFStripResponsiveImages This literally annoys me every single time I open up the mobile website on my iPhone.. Do we actually still need this 7 years after we introduced it ?

We have lazy loaded images now , so the only thing we are really saving on, is bytesize of the HTML due to the stripping of the srcset attribute....

Ideally we'd have Save-Data support on iOS by now and we could vary the response on that, but since that still hasn't appeared after 7 years......what if we progressively enhance the lazy loaded image by setting srcset from the lazy loading script ? And maybe only if the image or page loaded within a certain timeframe, we add the srcset ?

Firstly confirmed that this is a MobileFrontend issue. Apologies for the confusion. I think I must have confused this with the bug about the default image size.

I definitely think the MobileFrontend stripping is worth re-evaluating. It's not something I've given much thought to over the last few years.

My understanding is that any decision would need to be a joint recommendation by product (@ovasileva representing) and performance team.

Even with lazy loading, enabling srcset would increase the number of bytes downloaded for articles (minimally for articles with no images in the lead) but for users who read the articles, that would go up, but presumably with current web trends, this would be offsetted by things like Android's Data saver mode.

My understanding is part of the reason they were originally disabled was that in older devices srcset was leading to multiple downloads for certain images, but this should not be a problem in modern browsers. I also seem to recall some issues with memory that Peter may have flagged several years ago.

Technically obviously this is straightforward, but I think it requires a bit of thought, particularly for the regions with slower connections this optimization was designed for. If we wanted to we could probably assess APIs for conditionally adding them based on memory/connection speed (e.g. https://developer.mozilla.org/en-US/docs/Web/API/Navigator/connection comes to mind, but given it's experimental probably not the right one).

Retagged readers web backlog and performance team so this is not lost.

In T293303#7800467, @Jdlrobson wrote:

My understanding is part of the reason they were originally disabled was that in older devices srcset was leading to multiple downloads for certain images, […]

I'm not aware of such malfunction having existed in browsers.

I am aware of a brief period in our own specific history, where we used client-side JavaScript (mediawiki.hidpi.js), which inherently causes duplicate downloads, and did so for all browsers (when on a HiDPI device). First the native one from img-src when the browser first renders and scans for resources to preload, and then another when our JS changed that attribute to the URL of a higher resolution image. This code was not used for browsers after 2015, and I removed it as unused in 2018.

The reasoning for this change to mobile web can be found in T119797. The task and conversation there specifically mention bandwidth and make no mention of duplicate downloads.

This is interesting from Smashing Magazine on how many (in %) of their users use Data-Saver option:
https://www.smashingmagazine.com/2022/03/signals-customizing-website-user-experience/#and-is-it-used

It would be interesting to see what it looks like for us.

Idea from @dpifke: Capture data saver mode client side in a Statsv metric.

I am aware of a brief period in our own specific history, where we used client-side JavaScript (mediawiki.hidpi.js), which inherently causes duplicate downloads, and did so for all browsers (when on a HiDPI device

That's probably what I'm recalling. Good memory!

@nray @SCherukuwada I am wondering if this would be a good opportunity for collaboration with the performance team?

This sounds interesting. My capacity is pretty limited right now though, and I most likely won't be able to engage with this much until after the visual regression test project

It's October, it's the one year anniversary of this bug report. Images are still blurry. The only subtask has been declined.

How to proceed? How to help out as a volunteer?

Trying to summarize the discussion above, please point out where incorrect:

The only reason we added wgMFStripResponsiveImages is to save bandwidth, given that srcset is checked against display capabilities and not bandwidth.

The only suggestion I'm seeing here that might address this is the bit where @TheDJ said "And maybe only if the image or page loaded within a certain timeframe, we add the srcset ?"

Is there another option, aside from just measuring how bad it will be if we turn wgMFStripResponsiveImages off and see if that's an easy fix?

@Krinkle Do you have a recommendation on how to measure the potential impact on experience/bandwidth for the affected users (regardless which option we chooose)?

@Krinkle I'm somewhat confused by what we're talking about re: data saver mode. There's this one: here? And there's the saveData API that isn't supported by Firefox and Safari. The former doesn't exist any more, and the latter isn't adopted.

Change 885362 had a related patch set uploaded (by Ladsgroup; author: Amir Sarabadani):

[mediawiki/extensions/MobileFrontend@master] Completely get rid of responsiveimages removal

https://gerrit.wikimedia.org/r/885362

Change 890127 had a related patch set uploaded (by Nray; author: Nray):

[mediawiki/extensions/MobileFrontend@master] Don't add srcset attribute to lazy loaded image element in data saver mode

https://gerrit.wikimedia.org/r/890127

In T293303#8337960, @SCherukuwada wrote:

@Krinkle Do you have a recommendation on how to measure the potential impact on experience/bandwidth for the affected users (regardless which option we chooose)?

I was curious and explored the effects that this change could have on html and image payload size because why not 😊

The mobile site lazy loads most of the content's images after it appears within (or close to) the viewport. But typically the user has to tap on a section to expand it first. Therefore, I was interested in exploring two scenarios:

• Users who open one section and scroll all the way to the bottom of the page
• Users who open all sections and scroll all they way to the bottom of the page

The first is probably a more likely scenario than the latter, but the latter gives a better idea of the most popular upper bound.

To do this, I wrote a script that did the following:

• Downloaded the top 100 most popular pages for the month of January 2023
• For each page, it saved a "before" and "after" version. The "before" version contained the untouched html from the production mobile site. The "after" version used the exact same HTML but added the srcset attribute to each lazy loaded image (copying the desktop site's behavior), which simulates the effect 885362 will have when merged.
• Visited each page in a headless chromium browser simulating iPhone 11 behavior (e.g. using a device pixel ratio of 2)
• Clicked one section or all the sections, and then scrolled to the bottom of the page
• Recorded the sizes of the uncompressed html payload, compressed html payload, and total image payload.

These were the results:

Users who open one section

Out of the top 100 most popular pages for the month of January 2023:

• The median difference in total uncompressed html size is 613 B, while the maximum is 20.34 kB (Cleopatra)
• The median difference in total html transfer size (after gzip) is 71 B, while the maximum is 1.79 kB (Cleopatra)
• The median difference in total image transfer size is 0 kB, while the maximum is 675.21 kB (Elvis Presley)

Users who open all sections

Out of the top 100 most popular pages for the month of January 2023:

• The median difference in total uncompressed html size is 613 B, while the maximum is 20.34 kB (Cleopatra)
• The median difference in total html transfer size (after gzip) is 70 B, while the maximum is 1.79 kB (Cleopatra)
• The median difference in total image transfer size is 74.51 kB, while the maximum is 1.47 MB (Cleopatra)

Conclusion

Adding the srcset attribute to the lazy loaded images resulted in small increases in HTML size (71 B median increase in compressed transfer size, 613 B median increase in uncompressed transfer size) and larger increases in image payload size (0 B median increase when one section is opened and 74.51 kB median increase when all sections are opened).

• We can mitigate the effects of the image payload increase by taking advantage of data saver mode
• My script just measured the effects this change has on image/html payload, but it will be interesting to see the effects it has on other metrics (e.g. html parse time) from our synthetic test results

Change 890509 had a related patch set uploaded (by Nray; author: Nray):

[operations/mediawiki-config@master] Add static "Cleopatra" page to facilitate synthetic testing of 885362

https://gerrit.wikimedia.org/r/890509

Change 885362 merged by jenkins-bot:

[mediawiki/extensions/MobileFrontend@master] Completely get rid of responsiveimages removal

https://gerrit.wikimedia.org/r/885362

Change 890509 merged by jenkins-bot:

[operations/mediawiki-config@master] Add static "Cleopatra" page to facilitate synthetic testing of 885362

https://gerrit.wikimedia.org/r/890509

Mentioned in SAL (#wikimedia-operations) [2023-02-21T21:08:29Z] <catrope@deploy1002> Started scap: Backport for [[gerrit:890509|Add static "Cleopatra" page to facilitate synthetic testing of 885362 (T326147 T293303)]]

Mentioned in SAL (#wikimedia-operations) [2023-02-21T21:10:23Z] <catrope@deploy1002> catrope and nray: Backport for [[gerrit:890509|Add static "Cleopatra" page to facilitate synthetic testing of 885362 (T326147 T293303)]] synced to the testservers: mwdebug1001.eqiad.wmnet, mwdebug2001.codfw.wmnet, mwdebug1002.eqiad.wmnet, mwdebug2002.codfw.wmnet

Mentioned in SAL (#wikimedia-operations) [2023-02-21T21:18:58Z] <catrope@deploy1002> Finished scap: Backport for [[gerrit:890509|Add static "Cleopatra" page to facilitate synthetic testing of 885362 (T326147 T293303)]] (duration: 10m 28s)

Change 890127 abandoned by Nray:

[mediawiki/extensions/MobileFrontend@master] Don't add srcset attribute to lazy loaded image element in data saver mode

Reason:

https://gerrit.wikimedia.org/r/890127

Change 891982 had a related patch set uploaded (by Ladsgroup; author: Amir Sarabadani):

[mediawiki/extensions/MobileFrontend@wmf/1.40.0-wmf.24] Completely get rid of responsiveimages removal

https://gerrit.wikimedia.org/r/891982

Change 891982 merged by jenkins-bot:

[mediawiki/extensions/MobileFrontend@wmf/1.40.0-wmf.24] Completely get rid of responsiveimages removal

https://gerrit.wikimedia.org/r/891982

Change 893542 had a related patch set uploaded (by Nray; author: Nray):

[operations/mediawiki-config@master] Revert "Add static "Cleopatra" page to facilitate synthetic testing of 885362"

https://gerrit.wikimedia.org/r/893542