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

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.