Page MenuHomePhabricator

MultimediaViewer: Carousel images should not rely on browser-native lazy loading
Closed, ResolvedPublic

Description

The mobile image carousel renders every thumbnail with loading="lazy" (T405523), but native lazy loading leaves the preload lookahead entirely up to the browser and exposes no way to tune it. Measured on Titan (moon) with a phone-size viewport: Chrome fetched 6 of the 20 carousel thumbnails at page load (~1.4 MB via the 2x srcset candidates, out of a ~6.5 MB total strip), and its documented lazy-load distance thresholds grow as the connection gets slower — so the readers with the least bandwidth download the most. This network cost was also flagged in the carousel RfC discussion on enwiki.

Technical notes

We should replace the browser-managed deferral with carousel-managed loading: server-render only the first few items with a real src, emit data-src/data-srcset for the rest, and load those from carousel.js via an IntersectionObserver rooted on the carousel's scroll container with a horizontal lookahead of a few tiles.

Acceptance criteria

  • At page load, only the initially visible carousel tiles (plus a small lookahead) are fetched, independent of the browser's lazy-loading heuristics
  • Scrolling loads tiles progressively before they enter view, a fast fling does not download the tiles it sweeps past, and tapping any tile (loaded or not) opens the correct image in the viewer
  • Readers without JavaScript do not see blank carousel tiles

QA steps

Create a page with

For testing image carousel.

== Gallery ==

[[File:174_Red-legged_seriema_in_Encontro_das_Águas_State_Park_Photo_by_Giles_Laurent.jpg|1000px]]
[[File:Status_iucn3.1_LC.svg|thumb]]
[[File:OOjs_UI_icon_edit-ltr.svg|thumb]]
[[File:Cariama_cristata_map.svg|thumb]]
[[File:Cariama_cristata_Vienna2008.jpg|thumb]]
[[File:Seriamanail_(high_res).jpg|thumb]]
[[File:Cariama_cristataPCCA20051227-2025A.jpg|thumb]]
[[File:Red-legged_Seriema_RWD1.jpg|thumb]]
[[File:Cariama_cristata_(Rotfußseriema_-_Red-legged_Seriema)_-_Weltvogelpark_Walsrode_2013-02.jpg|thumb]]
[[File:Cariama_cristata_(Rotfußseriema_-_Red-legged_Seriema)_-_Weltvogelpark_Walsrode_2013-03.jpg|thumb]]
[[File:Cariama_cristata_at_Parque_das_Aves_(Foz_do_Iguaçu)-1.jpg|thumb]]
[[File:Red-legged_seriema_(Cariama_cristata)_head.JPG|thumb]]
[[File:Cariama_cristata_-near_Goiania,_Goias,_Brazil-8.jpg|thumb]]
[[File:Commons-logo.svg|thumb]]
[[File:Wikispecies-logo.svg|thumb]]
[[File:Wikisource-logo.svg|thumb]]

Ensure the first image in the carousel doesn't have a thumbnail URL /width corresponding to a width of 1000px

Event Timeline

Change #1307009 had a related patch set uploaded (by Eric Gardner; author: Eric Gardner):

[mediawiki/extensions/MultimediaViewer@master] Manually lazy-load carousel images beyond the first few

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

Change #1307011 had a related patch set uploaded (by Eric Gardner; author: Eric Gardner):

[mediawiki/extensions/MultimediaViewer@master] Use optimized thumbnail sizes for carousel items

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

HSwan-WMF triaged this task as Medium priority.Jul 7 2026, 5:09 PM

Test wiki created on Patch demo by EGardner (WMF) using patch(es) linked to this task:
https://2d40af3d44.catalyst.wmcloud.org/w/

Change #1307009 merged by jenkins-bot:

[mediawiki/extensions/MultimediaViewer@master] Manually lazy-load carousel images beyond the first few

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

Jdlrobson-WMF subscribed.

After checking with Sherry I went ahead and merged the patch to fix lazy loading. For some pages the article is downloading a considerably large amount of images so I think it was important this was fixed sooner. For the short period of time the image carousel enabled we were seeing a performance regression (increased recalculate style before least contentful paint).

I left some suggested changes in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/MultimediaViewer/+/1309725
Could someone other than me (maybe @matthiasmullie ?) review while I'm out and help finish @egardner 's patch up?

There's still work to do here per Jon's last note so going back to doing.

Change #1312551 had a related patch set uploaded (by Elliottetzkorn; author: Elliottetzkorn):

[mediawiki/extensions/MultimediaViewer@master] Use optimized thumbnail sizes for carousel items

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

Change #1309725 had a related patch set uploaded (by LWatson; author: Jdlrobson):

[mediawiki/extensions/MultimediaViewer@master] POC: Some suggested follow ups

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

Change #1309725 abandoned by LWatson:

[mediawiki/extensions/MultimediaViewer@master] POC: Some suggested follow ups

Reason:

follow-up change I81a21eb5ce9a0395107f9d5d72259522d9c7f748 includes suggestions from this proof-of-concept patch

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

Change #1307011 abandoned by LWatson:

[mediawiki/extensions/MultimediaViewer@master] Use optimized thumbnail sizes for carousel items

Reason:

follow-up change I81a21eb5ce9a0395107f9d5d72259522d9c7f748

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

Change #1312551 merged by jenkins-bot:

[mediawiki/extensions/MultimediaViewer@master] Use optimized thumbnail sizes for carousel items

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

The specs in the task description are basically fulfilled.

After checking with Sherry I went ahead and merged the patch to fix lazy loading. For some pages the article is downloading a considerably large amount of images so I think it was important this was fixed sooner. For the short period of time the image carousel enabled we were seeing a performance regression (increased recalculate style before least contentful paint).

After creating a test page (as per QA steps in the task prescription) and testing/comparing also https://en.wikipedia.beta.wmcloud.org/wiki/Triton_(moon) and https://en.wikipedia.org/wiki/Triton_(moon), I checked the following

  • loading pages with Network throttling to check Chrome's native lazy load (Fast 4G vs Slow 4G vs 3G vs 2G)
  • the number of request for different throttling values (should be more if Chrome fetches more aggressively on slow connection)
  • LCP and FCP values
  • running Lighthouse ( in DevTools (using incognito window) performance analysis on a page load.

The table below shows some values for current prod wmf.12 to compare with wmf.13

titlewmf.12wmf.13
https://en.wikipedia.org/wiki/Triton_(moon)FCP 2.7 LCP 2.7 performance score: 89%
https://en.wikipedia.org/wiki/Claude_MonetFCP 3.3 LCP 3.3 performance score: 66%
https://en.wikipedia.org/wiki/Barack_ObamaFCP 3.1 LCP 3.1 performance score 78%

Hi @Etonkovidova I think Lighthouse isn't good to measure changes in performance. There's a couple of technical reasons:

We have a section about it in our testing principles in https://wikitech.wikimedia.org/wiki/Performance/Synthetic_testing#Our_Web_Performance_testing_principles and I think I need to write it a little better.

To get reliable metrics (metrics where you can say that one implementation if slower or faster than another implementation) you need to run that test on a dedicated server. We have bare metal servers that only runs performance test that we can use. That way we are sure than nothing else on the server influence the metrics and we can also use packet level throttling and make many runs so we can be sure that the change (regression or win) is statistical significant.

There's two ways today we run those tests: Either by running them continuously around the clock. There's a git repo where you can commit URLs that you want to test (https://gerrit.wikimedia.org/g/performance/synthetic-monitoring-tests). You can either add tests that just access one URL or a user journey. Then you can either run this tests direct against Wikipedia or use replay server. The replay server runs locally on the machine "replaying" the content of Wikipedia so that the test will not be affected by backend/network and only measure frontend code changes.

You can also use https://wikiperformance.wmcloud.org that will use one of our bare metal servers to run the test. If you add tests there, it will be first in the queue and run when the agent is ready. There are some information on how to run tests in https://wikitech.wikimedia.org/wiki/Performance/Synthetic_testing/Run_a_test

There are more generic performance info on: https://wikitech.wikimedia.org/wiki/Performance/Synthetic_testing

Ping me and we can have a couple of sessions if you want to work together and see how we could measure these things!

Thank you, @Peter - I absolutely agree, and, from my previous testing experience on performance evaluation, I know how the tools provide, at the best, only rudimentary (and more often unreliable) feedback on performance.

For this specific case, I looked at the different aspects of what could be possible to evaluate, I mentioned them in https://phabricator.wikimedia.org/T430897#12152101 And, in the end, I was thinking that, probably, Lighthouse might give me a rough estimate of what numbers are now. to compare them to later.

Thank you for reaching out - let's have a chat sometime next week on practical approach to check performance. I'll definitely follow up.

@Peter and @Etonkovidova and @egardner, if you do any sessions on this I would love to join please!

@Peter and @Etonkovidova and @egardner, if you do any sessions on this I would love to join please!

Sure! I'll let you know.

Test wiki on Patch demo by EGardner (WMF) using patch(es) linked to this task was deleted:

https://2d40af3d44.catalyst.wmcloud.org/w/