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

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.

On Wed, Dec 3, 2014 at 4:05 AM, Yoav Weiss <yoav@yoav.ws> wrote:

> On Mon, Dec 1, 2014 at 9:35 PM, Aaron Gustafson <aaron@easy-designs.net>
> wrote:
>
>>
>> In April of last year, Jake brought up the "defer" attribute for images
>> (and other resources).
>>
> In reading the Resource Hints draft, the concept of lazy loading or
>> allowing the browser to determine the loading process, but to be aware of a
>> low-priority resource seems to have been lost. It was part of the
>> now-abandoned Resource Priorities draft (defer, lazyload).
>>
>
> I agree that the need for such de-prioritization/lazy-loading is still
> here. There are many large-scale sites that are using various JS based
> mechanisms in order to avoid loading all of the site's images.
> These mechanisms are often invasive, as there's no proper way to get
> notified regarding an element's visibility (or the fact that it's *about*
> to become visible). They also tend to ignore the radio characteristics,
> where a native solution could take advantage of that (e.g. download
> everything on a good radio network to avoid draining the battery, assuming
> a user pref indicates BW is cheap, etc).
>
> Also - as part of the Element Queries discussion, we may need a way to
> signal the parser that a certain image's download should not start before
> layout took place (since it is part of an EQ based layout, and its
> dimensions depend on the final layout, and cannot be hinted using a `sizes`
> like mechanism).
>
> So, I would very much like to see the discussion of such de-prioritization
> hints resumed.
>
>
>
>> The Resource Hints draft seems to focus entirely on prioritizing assets
>> and domains (which is understandable), but does not seem to offer an option
>> for de-prioritizing assets.
>>
>
> I don't think that Resource Hints is the place for such de-prioritization.
> Resource Hints are designed to let the browser know of resource URLs as
> soon as possible, whereas in this case, it's not needed.
>
>
>> Are we to assume that deprioritization would be the default behavior if
>> prioritization instructions are provided
>>
>
> No. The hints are not mandatory. Assuming they are would slow down
> existing Web content.
>
>
>> In not, where are we at with respect to a declarative de-prioritization
>> instruction?
>>
>
> Good question :)
>
>