I'm landing this in sprint 67, but we'll be discussing next steps on lazy loading stage gating.

I recommend we figure out how to get JS-based lazy loading working for ResourceLoader impaired, yet JavaScript capable UAs. Generalizing, there are roughtly two cases: compression proxy browsers and everything else.

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

• For UAs known to have JavaScript executed in a compression server environment (e.g., Opera Mini), iterate through all of the <div>s and make their content be <img> tags, but without qlow / chroma sub-sampling.
• For UAs with JavaScript executed in the client, attach the logic described earlier for lazy loading images. Consider chroma sub-sampling, but not qlow.

Notice the first point explicitly acknowledges that in common compression server environments JavaScript actually does execute at the server (cf. https://dev.opera.com/articles/opera-mini-and-javascript/). In this case the trick is to make the JavaScript run so the images are in the page when the binary document is delivered to the client. Once we've put the images in place, the compression server environments and their respective clients do further adaptive compression we can get for free, as before.

Notice that the second point does not exclude ResourceLoader impaired UAs from lazy loading. It's suggesting that if there's client side JavaScript support, we ought to use lazy loading for them.

We have left this in needs analysis as we need to talk about what a solution to this problem would look like. Hoping to setup a meeting with at least @Jhernandez, @Krinkle and myself.

@Krinkle and @Peter wrote down their thoughts here:
https://phabricator.wikimedia.org/T124390#1987128

The current approach shows no images for grade C browsers, but shows an image for browsers with JS disabled.
We should probably optimise for grade C browsers rather than browsers with JavaScript disabled.

We seem to have these options:
1) Do nothing (keep status quo)
Pros:

• Works for non-js users without any penalty

Cons:

• Grade C browsers see no images, only link.
• There are more grade C browsers than non-js users.

**2) Follow [[ https://jmperezperez.com/medium-image-progressive-loading-placeholder/

**Pros:

• non-js users see noscript image without any penalty
• Grade C browsers see a blurred image, depending on the level of blur may be somewhat useful for context.

Cons:

• Larger HTML.
• Non-javascript users make double the number of HTTP requests for images.
• HTTP requests for images is the same (albeit paylod is lower) - note we could use data-uris at expense of HTML size to avoid HTTP requests.
• Grade C experience is worse than non-js experience.

3) Show a blurred thumbnail and drop the noscript tag.
Pros:

• Grade C browsers and non-js users see a blurred image, depending on the level of blur may be somewhat useful for context.
• Both grade C and non-js experience is the same
• No HTML size change

Cons:

• Both grade C and non-js experience is sub-par to modern browsers running JS
• Number of HTTP requests is the same, which may still choke really slow / older devices.

4) Inject JavaScript in the HTML for grade C browsers that loads images on window.load
e.g. window.onload = function () { var nodes = document.getElementsByTagName( 'noscript' );};

Pros:

• Non-js still has support via noscript tag
• Grade C browsers see the full scale images

Cons:

• We are now supporting grade C browsers somewhat.
• Inline JS is nasty.

I guess the question is what are we trying to achieve here. What kind of experience do we want to give grade C browsers? Do we want to give them no images, a sub par image or the full image?

CC @Nirzar @JKatzWMF I strongly recommend that Grade C browsers with JavaScript (i.e., those in the blacklist see non-degraded images, which is option 4.

As the existing bootstrapper already works for enforcing specific behavior on the relevant clients, would it make sense to just get the necessary JS loaded into the bootstrapper?

A few of us discussed this and here are the notes:
https://etherpad.wikimedia.org/p/ImagesOnGradeCBrowsers

The preference is to go ahead with solution 4 and run some minimal JavaScript embedded in the HTML for grade C browsers to load images via the ResourceLoader NORLQ object.

Change 276026 had a related patch set uploaded (by Jdlrobson):
Allow us to distinguish grade C browsers from JS disabled browsers

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

Change 276052 had a related patch set uploaded (by Jdlrobson):
WIP: Add Grade C browser support

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

Patch is waiting on @Krinkle who was not sure about introducing a new class in the startup module.

Change 276026 abandoned by Jdlrobson:
Allow us to distinguish grade C browsers from JS disabled browsers

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

I'd like to have a brief chat about where exactly MobileFormatter::gradeCBrowserSupport should live. Otherwise, 276026 276052 LGTM.

@phuedx I've fixed up the patch.

Change 276052 merged by jenkins-bot:
Add Grade C browser support to lazy loaded images

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