[GOAL] Load images with care
Closed, ResolvedPublic

Description

As a Wikipedia mobile web user with a sometimes unstable, other times slow, and often metered connection I want my browser to only load images when I'm about to see them, so that I can see pages faster and can lower my bandwidth usage.

Lazy loading images and reducing the actual bytes transferred of images will likely improve initial page loading, will definitely improve full page load, and will generally reducing bandwidth consumed for the common cases.

This is a task for the earlier part of Q3 FY2015-2016 (January-March 2016) to build and deploy improvements on the mobile web beta channel on Wikipedia.

A multipronged approach should be used. Here's one way for articles.

Configuration

  • Provide for configuration to apply optimizations at the wiki/skin/namespace level such that this could be used on variety of configurations (including "desktop" skins, although the mobile web beta Wikipedias will in practice be first).

Concrete rollout

  • Quick and dirty solution.
  • Learn.
  • Replete solution and expand to Wikipedia on Minerva on beta mobile web generally. Q3 delivery is the target.
  • 1% rollout.
  • Then Wikipedia mobile web stable channel is the Q4 target, but earlier rollout delivers even more value to readers sooner.

Loading

  • Do not load images by default.
  • Reserve image placeholder space where images may eventually later be loaded.
  • If a page has been sufficiently loaded, initiate image downloads for images above the fold (special case: default load for first image may be sufficient, in other words no special treatment for it)
  • If a page has been sufficiently loaded but no images would be above the fold, if there would be images in the next screenful, initiate image downloads for the next screenful as soon as a scroll action occurs or the document has fully loaded, whichever occurs first.
  • For subsequent scroll action, initiate image downloading with pre-emptive loading of images one screenful ahead of time.
  • Trigger similar logic on sections when they are uncollapsed (e.g., Minerva on phone form factor as of January 2016).
  • For really small images (e.g., small icon flags), consider making the placeholder transparent but apply lazy loading logic to them.
  • For regular sized images, the placeholder is commonly something simple like grey and the image fades or pops in. An animated spinner may make sense, but if used should not utilize unnecessary CPU cycles (e.g., if animation state is executed despite a spinner being off screen).

Browsers

  • Use 1.0 pixel depth.
  • For UAs without <script> support, embed the simplest possible <noscript><img> tag (alt, src, width, height) per image.
  • Wrap the <noscript><img> tags in <divs>, embedding data such that JavaScript can construct full images according to whatever wiki spec is in place.
  • For UAs known to have JavaScript executed in a compression server environment (e.g., Opera Mini), iterate through all of the <div>s and make their content be displayed <img> tags.
  • For UAs with JavaScript executed in the client, attach the logic described earlier for lazy loading images. Consider chroma sub-sampling, but not qlow.

ResourceLoader should not be a strict requirement for the JavaScript behaviors. It's possible that it may make more sense to actually embed <script> in the <head> for pages that have crossed a certain image threshold (simplest heuristic is it contains two images). A nice complement to this would be <head> embedded <style>s for the above-the-fold content (or maybe the first couple screenfuls of content for some acceptable screen size).

Wikipedia Zero

Wikipedia Zero currently uses qlow to downsample images through image tag rewriting and the like. It should be examined to ensure compatibility. The approach outlined in this task would seem to confer even greater bandwidth savings - it may be worth considering whether it could be applied on Wikipedia Zero networks first, which is a twist on the netspeed cookie concept.

Search engines

Search engines may take screenshots of pages. This approach may or may not need to be tuned to accommodate this tech - but the impact on relative page ranking should be observed on a controlled set of articles in a production environment.

Metrics and instrumentation

Baseline and A/B measurement approaches should be defined, but the basic design should be figured out before instrumenting too heavily and having to throw away that instrumentation.

Related Objects

StatusAssignedTask
ResolvedJdlrobson
ResolvedJdlrobson
ResolvedJhernandez
ResolvedJdlrobson
InvalidNone
DeclinedNone
ResolvedJdlrobson
DeclinedBBlack
ResolvedJdlrobson
ResolvedJdlrobson
ResolvedJdlrobson
ResolvedJhernandez
ResolvedJhernandez
DeclinedNone
ResolvedJdlrobson
ResolvedJdlrobson
ResolvedJdlrobson
ResolvedJdlrobson
ResolvedSumit
DuplicateNone
ResolvedJdlrobson
ResolvedKrinkle
ResolvedJdlrobson
ResolvedJdlrobson
DuplicateNone
ResolvedJhernandez
ResolvedJhernandez
DuplicateNirzar
Resolveddr0ptp4kt
DuplicateNone
Resolvedovasileva
There are a very large number of changes, so older changes are hidden. Show Older Changes
dr0ptp4kt removed a project: Reading-Admin.

Change 280140 had a related patch set uploaded (by Krinkle):
speed-tests: Add samples for MobileFrontend lazy-load images

https://gerrit.wikimedia.org/r/280140

Change 280140 merged by jenkins-bot:
speed-tests: Add samples for MobileFrontend lazy-load images

https://gerrit.wikimedia.org/r/280140

I'm seeing a 14s saving on fully load time when I compare http://www.webpagetest.org/result/160329_QB_157K/ with http://www.webpagetest.org/result/160329_26_158S/

That said the first load we measure in https://grafana.wikimedia.org/dashboard/db/mobile-2g?panelId=32&fullscreen
is inconsistent with the static page in this test. @Peter I am a little concerned our own webpagetest jobs are not simulating a 2G connection correctly..

Peter added a comment.Mar 29 2016, 7:47 PM

I think WebPageTest has changed the default speed for 2G.

On http://www.webpagetest.org/result/160329_QB_157K/ we tested with 2G (28000/25600/1300), for the runs we use bandwidthDown 35000 bandwidthUp 32000 latency 1300 (before that was categorized as slow 2 g I think?

We can change the default if you want but the numbers will jump? The speed/connectivity is more a tool for us to make sure that we do progress and make the pages faster and not the "true" speed of 2G users.

Note since "wgMFMode":"stable" and not "wgMFMode":"beta" and mw.config.get( 'wgMFLazyLoadImages' ).stable is false lazy images will not load.
The config variable is added via MFLazyLoadImages onResourceLoaderGetConfigVars so I'm not sure how we can safely turn this on in current form.

Note since mw.config.get( 'wgMFLazyLoadImages' ).stable is false lazy images will not load.

Yeah, fixed in 89ad4e5f3c00 (backported as 5def60aa57). Uploaded fresh copies (ed829580ea), new urls:

I'd recommend to re-run any WebPageTest tests related to the previous urls.

Jdlrobson closed this task as Resolved.Apr 5 2016, 11:50 AM
Jdlrobson claimed this task.

Okay I ran these tests again on our local instance:
http://wpt.wmftest.org/result/160405_K3_7F/
http://wpt.wmftest.org/result/160405_PG_7G/

Before change:
fully loaded 22.787

After change:
fully loaded 18.942s

metricinstancebeforeafterdelta%
fully loadedwebpagetest38.541s25.210s13.33135%
fully loadedwpt.wmflabs.org22.78718.942s3.84517%

Both are positive but magnitudes different, so this opens a question for me - T131837

Jdlrobson reopened this task as Open.Apr 5 2016, 11:54 AM

Sorry don't know what happened there.

Doesn't block our goal so I've removed as blocking task. We should triage that accordingly.

Jdlrobson renamed this task from Load images with care to [GOAL] Load images with care.May 17 2016, 4:54 PM

Untagging sprint 73, as not all the tasks are in sprint 73.

Peter added a comment.Jun 7 2016, 6:33 AM

This is interesting "30% of smartphone-dependent Americans say that they “frequently” reach the maximum amount of data that they are allowed to consume as part of their cell phone plan, and 51% say that this happens to them at least occasionally": http://www.pewinternet.org/2015/04/01/us-smartphone-use-in-2015/

Would be great to know how this looks in other countries too.

bd808 removed a subscriber: bd808.Jun 7 2016, 4:45 PM
leila added a subscriber: leila.Jun 20 2016, 9:58 AM
leila added a subscriber: ezachte.
Jdlrobson closed this task as Resolved.Sep 23 2016, 11:20 PM

This goal was achieved.