See T124390 for rationale.
The #reading-web engineers and collaborating #performance-team engineers defined the acceptance criteria (AC) for this task in the [Reading Web Performance Planning meeting on Monday, 25th January 2016](https://etherpad.wikimedia.org/p/ReadingWebPerformancePlanning).
It seems GitHub user [@mudkipme](https://github.com/mudkipme) had a go at this already and we would do well to learn from their example: https://github.com/mudkipme/mediawiki-lazyload
### Acceptance Criteria
* [] Feature flagged and disabled by default (we should be careful not to clash with other experiments). Mode agnostic (we can always enable on beta only at a later date)
For UAs without JavaScript support:
* [ ] Wrap `<img />` elements in `noscript` tags (ignore browsers which support JS but ResourceLoader does not support for the time being) outside the lead section where the lead section is defined as section number > 0. Avoid using the MobileFormatter for this. It could be done much more cleanly/efficiently using Parser hooks.
For UAs with JavaScript support:
* [ ] Defer loading of images outside of the user's viewport
** If the user hasn't scrolled, then defer loading of images below the fold
** When the user scrolls, then initiate loading of images that are about to enter the viewport
*** Image loading should initiate when the image is less than 3x pixels away where x is the height of the viewport.
* [] Images that have not been loaded are either a single colour base 64 image or div with correct width and height dimensions [nirzar to clarify]
* [ ] A loading indicator is shown if the user scrolls to it whilst the image is loading [nirzar to clarify]
* [] The loading of an image should not cause a repaint or jerk in the experience of a user, i.e. the loading of an image should not cause a reflow of the content.
Note: https://github.com/mudkipme/mediawiki-lazyload