I think we miss Other browsers (Firefox 48 in Kai OS for example) should not load images by default and instead have click to load functionality (as suggested by @Gilles). Needs an product decision and I think if you try Wikipedia on a Kai OS device you will agree. from T246866.

I think the SEO thing is number 2, It's important for our users. Google highlights this because it is making the experience bad for some users.

If you haven't tested what slow JS for lazy loading looks like on a slow device, please look at my two videos in T246767. Another good thing to test is loading an article with images (desktop version) on your mobile phone. Most browser have some indication of when the page is finished downloading and that will continue to move/spin until everything is ready, giving a bad experience.

What I mean is that what we do today is good, and we should make sure every user gets a good experience and that I like @Gilles idea of clicking on images to downloading them on slow devices.

I'm proposing solution 1 which includes using MutationObserver as well as "click to tap". I'd like to check in with the team that this is the right solution before fleshing out some developer notes explaining how that would work and what it would entail.

I want to add one thing after looking more into our metrics from Google. I think our fear for SEO penalties for first input delay on mobile was too high. It started with the SEO console warning emails but now when I looked at how we are doing I think we are doing good on first input delay. However the videos I shared show that our current lazy loading is a real problem for users.

At the moment it seems like Google judge us on two metrics: First Contentful Paint (for us that is the same as first paint) and First Input Delay.
The metrics are divided into three buckets: Slow, moderate and fast. For First Contentful Paint fast means the metric happens between zero and one second, moderate means between 1-3 seconds and slower than three seconds mean slow. For First Input Delay the limits are 0-100ms, 100-300ms and above 300 ms.

Google use the 75th percentile for First Contentful Paint and the 95th percentile for First Input Delay.

Looking at the metrics for mobile for the whole English Wikipedia the numbers looks like this:

Checking one page (Barack Obama!) on mobile:

I also looked at the Chinese Wikipedia (let me know if I should collect metrics for another wiki) :

My conclusion is that First Input Delay (at the moment) is not a problem for SEO and long term we should focus on First (contentful) paint.

I've added the pie charts/graphs at a new dashboard I'm working on: https://grafana.wikimedia.org/d/cZgMg49Wz/performance-summary

Some recordings from January when I noticed the same issue on the Nokia 8110 4G and JoiPhone devices (KaiOS feature phones).

This compares https://en.m.wikipedia.org/wiki/Banksy to https://en.m.wikipedia.org/speed-tests/Banksy.enwiki.872156204/ where the latter is a static snapshot frozen in time. The only difference between it and the real version is that the client-side pipeline stops after phase 2 (we init the inline scripts, startup and and base modules; but not the additional JS modules queued by core/skins/extensions).

This compares https://en.m.wikipedia.org/wiki/Grace_Hopper and its "View desktop" version.

Nothing new I think, but just wanted to share them for comparison to show that it happens on other pages/devices as well, and to perhaps help narrow down or re-confirm the common cause.

Change 587893 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/extensions/MobileFrontend@master] POC: Lazy loading with IntersectionObserver

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

My intuition was more that tapping the thumbnail once would load just that thumbnail and tapping it again would open the media viewer, but this is totally a product decision! As far as performance is concerned, the current implementation is everything we were hoping for.

Change 588028 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/skins/MinervaNeue@master] Cleanup: Remove unnecessary lazy loading wire up code

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

@ovasileva given the impact of this one, would it be okay to move this into code review now that the board is a little clearer?

In T246838#6134892, @Jdlrobson wrote:

@ovasileva given the impact of this one, would it be okay to move this into code review now that the board is a little clearer?

Sounds good

Change 587893 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@master] Lazy loading with IntersectionObserver

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

@Peter @Krinkle @Gilles patch should land next week. Is there anything we can do to get a sense of the impact of the change? Can the metrics in T246838#5997542 be used?

👏

Once this is proven successful in production, how difficult do you think it would be to adapt this code for it to work on Desktop as well? There are huge savings to be had there, and now that we have an efficient method for it, I think it would be a good time to make it work on both platforms.

As for impact, our usual telemetry should capture it. It's hard to say if any global metrics will be impacted significantly, but I can look at slow devices in particular, as this is where I think there is likely to be a visible change. Let me know the exact date it's been deployed to enwiki and I'll do a one-off before/after comparison for mobile devices bucketed by effective processing speed.

Change 588028 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Cleanup: Remove unnecessary lazy loading wire up code

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

As for impact, our usual telemetry should capture it. It's hard to say if any global metrics will be impacted significantly, but I can look at slow devices in particular, as this is where I think there is likely to be a visible change. Let me know the exact date it's been deployed to enwiki and I'll do a one-off before/after comparison for mobile devices bucketed by effective processing speed.

@Gilles this was deployed on 2nd June and should be live now.

x

Once this is proven successful in production, how difficult do you think it would be to adapt this code for it to work on Desktop as well? There are huge savings to be had there, and now that we have an efficient method for it, I think it would be a good time to make it work on both platforms.

There's an open ticket @ T148047 - I think the challenges around doing this in desktop are mostly around the many printed mediums and ensuring images continue to load in them e.g. printable=yes (also deciding what to do with responsive images - we disable those in mobile)

I've taken a tour of our metrics and can't see a visible change, but then again we don't have any metric that captures rendering smoothness directly. First Input Delay had a big move around May 28 in CruX, but that applied to other websites as well, so it's probably Google changing something on their end.

As for our own collection of FID, I don't see a visible difference around June 2 either:

https://grafana.wikimedia.org/d/9zeb91jWk/first-input-delay

This isn't to say that the UX hasn't improved, since those metrics are only indirectly affected by this improvement. There are likely less frame drops than there used to be, it's just that it would be very expensive to measure that currently. There are discussions within the W3C web perf working group about new metrics that would allow to capture that.