Change Details

On 2G the Barack Obama page hits first paint at 40s with images and 20s without images [2]. In the former the page doesn't fully load, however in the latter it does (albeit sans images). This is pretty huge. Run a test for yourself using the settings: ``` setCookie https://en.m.wikipedia.org enwikidisableImages=1 navigate https://en.m.wikipedia.org/wiki/Barack_Obama ``` Daring proposal: We currently allow the disabling of images via the enwikidisableImages cookie - why not do it for all page views. (hear me out...) Currently the disable images mode replaces images with a link to the file page for the image (mw-mf-image-replacement class). If we were to also decorate this with a data attribute pointing to the source of the image, we could load these images via JavaScript at the bottom of the page. A more complete solution would only do this for images beyond the lead section (given that the first image is likely to be the only one the user needs to see to feel like the page is responsive). Given the images would then be loaded after the startup module, things could get ridiculously more fast. Proposal: Let's try this out and test it and report back findings. Let's avoid a debate about whether this is considered breaking the web at this point - let's just work out what it buys us. [1] http://www.webpagetest.org/result/150825_9V_1AYZ/ [2] http://www.webpagetest.org/result/150827_ZB_1A46/

On 2G the Barack Obama page hits first paint at 40s with images and 20s without images [2]. In the former the page doesn't fully load, however in the latter it does (albeit sans images). This is pretty huge. Run a test for yourself using the settings: ``` setCookie https://en.m.wikipedia.org enwikidisableImages=1 navigate https://en.m.wikipedia.org/wiki/Barack_Obama ``` Daring proposal: We currently allow the disabling of images via the enwikidisableImages cookie - why not do it for all page views. (hear me out...) Currently the disable images mode replaces images with a link to the file page for the image (mw-mf-image-replacement class). If we were to also decorate this with a data attribute pointing to the source of the image, we could load these images via JavaScript at the bottom of the page. A more complete solution would only do this for images beyond the lead section (given that the first image is likely to be the only one the user needs to see to feel like the page is responsive). Given the images would then be loaded after the startup module, things could get ridiculously more fast. Proposal: Let's try this out and test it and report back findings. Let's avoid a debate about whether this is considered breaking the web at this point - let's just work out what it buys us. Changes required: * With a flag enabled e.g query string parameter AND disableImages cookie enabled any disabled images are pulled in via JS (when scrolled to - see getBoundingClientRect / debouncing) We'll get this deployed and run some tests across a collection of pages in both modes and report back what we find [1] http://www.webpagetest.org/result/150825_9V_1AYZ/ [2] http://www.webpagetest.org/result/150827_ZB_1A46/

On 2G the Barack Obama page hits first paint at 40s with images and 20s without images [2]. In the former the page doesn't fully load, however in the latter it does (albeit sans images). This is pretty huge. Run a test for yourself using the settings: ``` setCookie https://en.m.wikipedia.org enwikidisableImages=1 navigate https://en.m.wikipedia.org/wiki/Barack_Obama ``` Daring proposal: We currently allow the disabling of images via the enwikidisableImages cookie - why not do it for all page views. (hear me out...) Currently the disable images mode replaces images with a link to the file page for the image (mw-mf-image-replacement class). If we were to also decorate this with a data attribute pointing to the source of the image, we could load these images via JavaScript at the bottom of the page. A more complete solution would only do this for images beyond the lead section (given that the first image is likely to be the only one the user needs to see to feel like the page is responsive). Given the images would then be loaded after the startup module, things could get ridiculously more fast. Proposal: Let's try this out and test it and report back findings. Let's avoid a debate about whether this is considered breaking the web at this point - let's just work out what it buys us. Changes required: * With a flag enabled e.g query string parameter AND disableImages cookie enabled any disabled images are pulled in via JS (when scrolled to - see getBoundingClientRect / debouncing) We'll get this deployed and run some tests across a collection of pages in both modes and report back what we find [1] http://www.webpagetest.org/result/150825_9V_1AYZ/ [2] http://www.webpagetest.org/result/150827_ZB_1A46/