Page MenuHomePhabricator

[SPIKE] Verify lazy loading images doesn't break Wikipedia Zero
Closed, ResolvedPublic


As I recall we had resolved to avoid breakage in Wikipedia Zero with image lazy loading, as opposed to trying to code around the MobileFrontend markup for image lazy loading in the ZeroBanner extension itself. With this said, can someone confirm things work okay with ZeroBanner when image lazy loading is in force?
Here's the relevant block of code in ZeroBanner involving image rewriting:
There are two cases treated in that code:

  1. User is on a subdomain of user has to tap through to get to images. It would be surprising if images started showing up all of a sudden without user intervention to get at them. So-called zerodot use is really low, though, almost to the point of it being decommissioned; most Wikipedia Zero usage is on mdot.
  2. User is on an operator network where the configuration is set for image downsampling with the qlow quality parameter. If I understand correctly, it is the data-src attribute that is actually used for obtaining the image by the lazy loading JavaScript, so my read of the code suggests maybe PageRendering.php wouldn't apply the transform (meaning only the <noscript> code would have downsampled images: an unexpected victory for <noscript> users). But this lack of transform would be offset by less image bandwidth in general.

In either case if things are mistreated yet there isn't breakage (exceptions, etc.) we should just file a bug and get stuff fixed. If fixes are required, I don't think it has to block stuff if we can get it to ride a train for the week following next (sure, if it can ride the train next week even better, though).

Related Objects

Event Timeline

phuedx created this task.Mar 18 2016, 9:42 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 18 2016, 9:42 AM

here's my analysis on

  • The MobileFrontendBeforeDOM hook runs at the start, before transformations, so where Zero is replacing images these pages will not be impacted by lazy loaded images
  • The code to reduceImgQuality is relatively hacky and arguably a micro-optimisation that should be removed with lazy loaded images. The data savings will be far greater for network providers by lazy loading images then they will be to apply qlow. We are already stripping srcsets by default.
  • The block for watchlist code should be removed. This hook is never invoked for special pages (see If this is wanted we should look to provide an option in MobileFrontend
  • Links will not be impacted by lazy loading images

Here are my notes:
@jhobs we can test this by setting the correct headers and visiting as if a Zero user. I'm having difficulty verifying this. Can you double check ? Or @dr0ptp4kt if you remember how?

Here are my notes:
@jhobs we can test this by setting the correct headers and visiting as if a Zero user. I'm having difficulty verifying this. Can you double check ? Or @dr0ptp4kt if you remember how?

I believe we'll actually have to add an IP to our testing config (Zero:TEST). Faking the headers seemed to stop working a while back and it's always hit a different code route than doing it genuinely anyways due to varnish.

I've verified this as working when my IP was added to the test config.

Jdlrobson closed this task as Resolved.Apr 6 2016, 5:21 PM
Jdlrobson claimed this task.
dr0ptp4kt added a comment.EditedApr 7 2016, 4:50 PM

I see this task was closed. I take this to mean the following. @jhobs, can you confirm?

  • Users in beta on subdomains aren't getting images loaded accidentally
  • JavaScript users in beta on subdomains are getting lazy loading images
  • <noscript> users in beta on subdomains are getting images (and when the configuration has image downsampling, these specific users are getting downsampled images with "qlow" in the image URLs)

Sorry, forgot to reply to this yesterday even though I left the tab up... Yes, we're all good from my testing.