- From: Schurman, Eric <ericsc@amazon.com>
- Date: Thu, 22 Jan 2015 23:00:36 +0000
- To: "public-web-perf@w3.org" <public-web-perf@w3.org>
Has there been any more thought on deprioritizing assets? Being able to apply to specific elements something like the "lazyload" attribute specified in Resource Priorities (https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.html) would have directly met some needs that we have. Subtrees would be great too. On Wed, Dec 3, 2014 at 10:17 PM, Nat Duca <nduca@google.com> wrote: > >> With the ever-growing importance of mobile devices, I think its important >> to remember that client-side cpu costs are a critical part of performance. >> This is especially visible when you have serviceworker-based pages, because >> client costs start to dominate page load. >> >> Client side costs are many and varied but basically mean that >> optionality/de-prioritizing/prioritization needs to begin at the start: at >> elements. For instance, while the download of an <img> tag is important, >> you still have to decode and resize its pixels, and possibly upload it to >> the gpu. Or if you have a <video> element that is offscreen, even when you >> do start downloading it, the client-side costs of playing it can be huge. >> If you have a blob of html, then you have to parse it, construct its >> elements, style resolve, reflow, paint, rasterize, composite it. These >> steps can take hundreds of milliseconds. >> >> From a user experience point of view, these client side costs manifest as >> either bad speed indices, jank, or battery draining web sites. None of >> these are good. >> >> Thus, my hope is that we can broaden priority discussions a bit to include >> the full web platform stack, instead of being network-focused. For >> instance, a style property for making an element optional, or callbacks >> when elements become near to (or far from) the viewport, or the >> long-debated element-specific-raf. >> >> >Sure. All of these sound like things that we should definitely discuss. I'm >just not sure if these things would be better off under a single mega-spec, >or broken into their own, smaller specifications. I suspect the latter may >be more maintainable. > >Maybe optional elements can be mixed with HTML imports/Web components, and >we could avoid their download altogether when not needed? > >Visibility API (events when element approach/reach viewport) would have >been great to implement lazy loading, and would be great to explain it once >native lazy loading is there. Same goes for radio-up/radio-down events. > >As far as images go, we could also say that the only reason we need hints >to lazyload images is the fact that Web compat requires image download >before onload. Authors could also provide a page-wide hint to say "I don't >care about images in my onload. You, the browser, can lazyload everything, >if you find it helpful". >That would complicate life for the preloader (no notion of viewport there, >so no idea which images are visible), but the download queue could then use >heuristics to download only the first X images, and wait for layout for the >rest, etc, etc. The browser is in a better position to do that. > >
Received on Thursday, 22 January 2015 23:01:05 UTC