NOTE: Please watch {F31659369} vs {F31659370} to understand how this impacts users.
NOTE: Tap to click will be implemented separately in T246767
Google is actively focusing on performance penalties on "slow events" for search results. We have a slow event every time a section is expanded and lazy loaded images loaded. It's not exactly clear when this will become enforced but the penalties are already present in Google betas. Best guess - April.
The performance team and reading web met to discuss solutions.
## Proposed Solution
#### We reimplement lazy loading images using a MutationObserver or tap to show image pattern
This is the arguably the best and most complete solution. In an ideal solution we would use the MutationObserver and use a "tap to show" pattern on browsers which do not support MutationObserver (e.g. KaiOS). It however would likely be the most complex solution in terms of effort on our part.
Winners: smart phone users, feature phone users, designers
Losers: product, devs
More info: T225946#5916039
## Developer notes
Mutation/Intersection Observer is not available in < IE11, Chrome < 26, Safari < 7
The tap to show pattern will be implemented separately as part of T246767. In the mean time we will load all images for KaiOS browser.
You can use the content provider to test this (but note the open bug here > https://gerrit.wikimedia.org/r/c/mediawiki/extensions/MobileFrontend/+/585537)
Since lazy loading images is only required on the mobile domain this code can be moved to mobile.init and the old code relating to transforming burned to start from scratch. The lazyLoad code is still good.
https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/MobileFrontend/+/587893
## Rejected solutions
#### Use native image loading on Chrome only
Since Chrome is likely the browser SEO penalties will apply in we could use this fact to our advantage.
This would lead to a loss of control in the experience on Chrome and would hopefully be the lowest cost solution. On the short term this would break images displaying in printed PDFs (to be confirmed) and it's possible that we may lose some control over when lazy images are loaded and the transitions for when they display.
If we take this option we'd need to weigh up the trade offs here.
Winners: Product (done quicker!), Chrome users
Losers: product ([[ https://bugs.chromium.org/p/chromium/issues/detail?id=875403&q=component%3ABlink%3ELoader%3ELazyLoad&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified | breaks print! upstream bug ]]), devs, designers
#### Use native lazy loading everywhere
This is the most simple solution. It should be simple to implement and it would remove code maintenance.
However [[ https://caniuse.com/#feat=loading-lazy-attr | browser support for native lazy loading ]] `loading="lazy"` is low so browsers other than Chrome and Firefox would now load bandwidth - most notably iOS would no longer load images lazily meaning additional data usage for many of our users.
Winners: Product, Chrome+Firefox users
Losers: devs, designers, iOS users
## Developer notes
Meeting notes can be found here: https://etherpad.wikimedia.org/p/Desktop_Refresh_Performance
# QA steps
Smoke test:
- Visit https://en.m.wikipedia.beta.wmflabs.org/wiki/Albert%20Einstein on mobile as an anonymous user
- Scroll the article. Make sure that as the images scroll into view they appear and/or when you open sections.
- Disable JS, check the images appear also.
Repeat the smoke test on other articles using exploratory testing. Note this change only impacts articles which have images in subsections so make sure the articles you test on have images inside a collapsed subsection.
Disa
# sign off steps
[] Check in with performance team about next steps
[] Make sure the follow up patch https://gerrit.wikimedia.org/r/#/c/mediawiki/skins/MinervaNeue/+/588028/ has landed