- From: James Simonsen <simonjam@google.com>
- Date: Tue, 1 Oct 2013 13:46:03 -0700
- To: William Chan (陈智昌) <willchan@chromium.org>
- Cc: "public-web-perf@w3.org" <public-web-perf@w3.org>
Received on Tuesday, 1 October 2013 20:46:29 UTC
On Tue, Oct 1, 2013 at 12:23 PM, William Chan (陈智昌) <willchan@chromium.org>wrote: > Sorry if this has already been raised. If so, please just point me to the > relevant thread. > > Anyway, here are some use cases I'm looking at: > * Don't wake up the radio. This is not an interactive network request, > just fire it off whenever convenient. E.g. analytics. It's silly to wake up > the radio and waste power just to fire off this request. > This sounds like Beacon. https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/Beacon/Overview.html > * Downloading a large chunk of data in the background. Let the user agent > know that if there's contention, this network request should yield to any > interactive one. E.g. web apps can download their next version (which may > be large), sort of like how applications like browsers auto-update. You > don't want this to contend with interactive browsing though. > This sounds sorta like lazyload. Is that good enough? Otherwise, it sounds like it's just a more extreme form of it. Also, this makes me think of Service Workers. Maybe we should reach out to them about incorporating lazyload. James
Received on Tuesday, 1 October 2013 20:46:29 UTC