See T124390 for rationale.
The #reading-web team 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 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.
* [ ] Show a loading indicator whilst the image is loading
** **Suggestion**: Inline this asset in order to knock out a request for //another// image
* [] 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