Summary as of June 2026:
@Krinkle wrote at T148047#12052408:MobileFrontend shipped a JavaScript-based implementation for lazy loading images in 2016.
In 2019, the Performance Team implemented a native solution in MediaWiki core as a progressive enhancement (T230897). This feature flag remains disabled by default as of 2026 due to unresolved issues with printing (including save/export to PDF).
Upstream bugs with print mode:
- Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=875403
- WebKit: https://bugs.webkit.org/show_bug.cgi?id=224547
In 2020, the JavaScript-based solution in MobileFrontend was rewritten using IntersectionObserver to avoid slow synchronous event handlers while scrolling (especially impactful on KaiOS). See T246838 and T246767.
In 2024, @TheDJ ported the native solution in MediaWiki core from legacy Parser to a Parsoid transform (limited to MobileFrontend and Parsoid-enabled wikis) as part of T230812. This is enabled in production e.g if you manually enable Parsoid on a page https://en.wikipedia.org/wiki/Canada?useformat=mobile&useparsoid=1.
Chrome fixed the print issue for desktop in 2022, but it appears to remain unresolved for Chrome Mobile (Android). It also remains unresolved in Safari, although for desktop Safari there's a workaround that TheDJ found (ref).
Fast-forward a few years and as of 2026, Parsoid is enabled on a lot of wikis. And while it is not yet enabled on enwiki as a whole, it is enabled for 100% of mobile web pageviews since April 2026 (T424880). As a result, native image lazy loading is enabled for all of these as well. But, we still haven't enabled it for desktop (i.e. the current task).
Note that the Parsoid implementation remains local to MobileFrontend and there are tasks to bring this into Parsoid itself and/or MediaWiki core, which is effectively a prerequisite for this task because enabilng $wgNativeImageLazyLoading would not ineffective for desktop on Parsoid-enabled wikis (T324158).
Original 2016 task description by @Jdlrobson:After the success of https://blog.wikimedia.org/2016/09/19/mobile-web-improvements/ we should explore making the same changes in core (feature flagged of course) as the savings to be had are equally big (if not larger - there is an opportunity to save the cost of running Wikipedia if the bytes savings are significant).
Most of the code can easily be upstreamed with the exception of the MobileFormatter logic which would now be able to run in the parser.