So if I understand correctly, the test plan is to

• change the images in the HTML to low-res for everyone
• use Javascript to magick it back to normal for 95% of the users
• if that test goes well, maybe figure out how the 95% (ie. users with NetSpeed A) can get normal images by default

I still think that's a fundamentally broken strategy.

In T120875#1863937, @Tgr wrote:

So if I understand correctly, the test plan is to

• change the images in the HTML to low-res for everyone
• use Javascript to magick it back to normal for 95% of the users

Nope test would be to send 5% of users low res images, with JavaScript to magic it back.
Another 5% of users would get normal images with srcset attribute removed (working on assumption T119797 shows positive results)

We'd the compare the impact of these two buckets across the whole site.

• if that test goes well, maybe figure out how the 95% (ie. users with NetSpeed A) can get normal images by default

The data above would inform us on the benefits of such an approach. There would be several options:

• Serve low res thumbnails to all users and enhance
• Serve low res thumbnails only to users on a slow connection and enhance
• Keep the status quo.

I still think that's a fundamentally broken strategy.

Suspend disbelief until we have some data :)
If it's good enough for a global news site (e.g. BBC) I'm confident this can be justified but right now I'm just keen to get that data.

umm, what about interactions with parser/varnish cache? I'm not sure that it will be only 5% seeing this.

In T120875#1864122, @Jdlrobson wrote:

Suspend disbelief until we have some data :)

A fundamentally broken testing strategy, I meant. But apparently Ori implemented the cache splitting in the meantime:

• https://gerrit.wikimedia.org/r/#/c/257496/
• https://gerrit.wikimedia.org/r/#/c/256360/

I am a bit confused what this task is about as it's title says "default for all page views", but taken together with those patches the experiment plan seems reasonable. You'd have to make sure to run it for long enough to overcome the cold cache effect for the low-res/no-srcset variants.

Is the qlow JPEG setting what you meant by 1/3 size? I got the impression earlier that you were talking about using 1/3 resolution images (ie. when the parser wants a 300px image, return a 100px one and scale it up via CSS). The quality reduction from high JPEG compression seems pretty small.

qlow JPEG setting would be a good start yes given the promising results from Tim in https://phabricator.wikimedia.org/T119797#1867024

I don't see why everyone would not want to benefit from this (with the chance to opt out)

In T120875#1864141, @Bawolff wrote:

umm, what about interactions with parser/varnish cache? I'm not sure that it will be only 5% seeing this.

The cache is varied on "NetSpeed" cookie.

An opt-out does not prevent people from being outraged over a change they don't like. I had to learn that the hard way :-)

And of course additional preferences always mean a mental burden, borne disproportionately by those who don't use the site a lot. Most of the readers probably wouldn't even realize it's optional (how often do you open the preferences menu of, say, the New York Times? You probably never did, although you probably do read articles there every once in a while).

@bmansurov played around with this in https://gerrit.wikimedia.org/r/#/c/248312

@Tgr history shows little evidence of outrage for changes in the mobile site and I think this such change will be far less noticeable given most images are below the fold. Given the prevalence of 2G connections I'm confident we can build a strong case for why this is being done.

I believe we should not apply qlow to JavaScript capable UAs.

I do however recommend we apply qlow or chrome subsampling by default to <noscript> UAs, and as with convention in Wikipedia Zero, only in the context of an article (i.e., not File: pages). When the user taps through from the article the user can get to the more bandwidth intensive images on File: pages and their sublinks.

This is expressed in T124390: [GOAL] Load images with care as follows:

For UAs without <script> support, embed the simplest possible <noscript><img> tag (alt, src, width, height) per image and use the qlow / chroma sub-sampling type approaches.

I do think we should also consider chroma sub-sampling, but not qlow, for JavaScript capable UAs. This is expressed in T124390: [GOAL] Load images with care as follows:

For UAs with JavaScript executed in the client, attach the logic described earlier for lazy loading images. Consider chroma sub-sampling, but not qlow.

However, I think tasks like T126793: Lazy loading images breaks ResourceLoader-blacklisted JavaScript clients come ahead of these optimizations, as we need to first get things right for ResourceLoader impaired, yet JavaScript capable UAs.

This conversation is happening at too many places. Given that we have no specific plans for experiments anymore, can we merge this into T119797: Serve low-res images by default to users on slow or metered mobile connections (and possibly drop the "slow or metered" part if using the netspeed cookie is not considered anymore)?

In T120875#2048070, @Tgr wrote:

This conversation is happening at too many places. Given that we have no specific plans for experiments anymore, can we merge this into T119797: Serve low-res images by default to users on slow or metered mobile connections (and possibly drop the "slow or metered" part if using the netspeed cookie is not considered anymore)?

Agreed. @Jdlrobson, okay to abandon this T120875, or are you wanting to keep this for a rainy day? This task doesn't seem to block T124390: [GOAL] Load images with care, although I was curious if you wanted to keep the task open for a rainy day later on.