Currently, background fetches are only performed via GCM Scheduler on Android. Such fetches happen independently of the fact whether Chrome is running or not (is started, when not running).
We should introduce background fetches that happen only when Chrome is running. There are several advantages:
- reacts to _current_ usage of Chrome and thus prioritizes users that are currently active;
- is much more flexible than GCM as it can react to Chrome-internal events;
- does not start up Chrome (causing slowdown and battery strain).
The action plan is the following:
1) Refactor scheduling out of RemoteSuggestionsProvider into a new scheduler class.
2) Introduce soft fetches API in the scheduler, and make use of them by implementing a repetitive background timer triggering soft fetches (including random jitter of ~30 minutes).
3) Add other hooks to trigger soft fetches:
- Chrome startup (with the intent to open the browser window; after a small random delay);
- opening a NTP;
- becoming online over wifi (after a small random delay);
4) Add an experiment to update the UI before the user scrolls-below-the-fold
Currently, background fetches are only performed via GCM Scheduler on Android. Such fetches happen independently of the fact whether Chrome is running or not (is started, when not running).
We should introduce background fetches that happen only when Chrome is running. There are several advantages:
- reacts to _current_ usage of Chrome and thus prioritizes users that are currently active;
- is much more flexible than GCM as it can react to Chrome-internal events;
- does not start up Chrome (causing slowdown and battery strain).
The action plan is the following:
1) Refactor scheduling out of RemoteSuggestionsProvider into a new scheduler class.
2) Introduce soft fetches API in the scheduler, and make use of them by implementing a repetitive background timer triggering soft fetches (including random jitter of ~30 minutes).
3) Add other hooks to trigger soft fetches:
- Chrome startup (with the intent to open the browser window; even on cellular; after a small random delay);
- opening a NTP (even on cellular; immediately);
- getting online (only over wifi; after a small random delay);
(maybe allow a remotely configurable blacklist of triggering points so that we are in control)
4) Add an experiment to update the UI before the user scrolls-below-the-fold
5) Add metrics to enable assessing the improvement:
- age of impressed snippets as a difference of impression time and _fetch_ time;
- track on startup whether a soft fetch has been performed or not;
- allow to track how many soft fetches per day have been performed.
Comment 1 by jkrcal@chromium.org
, Dec 8 2016