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.