Re: [resource-hints] Resource de-prioritization?

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