W3C home > Mailing lists > Public > public-web-perf@w3.org > January 2015

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

From: Ilya Grigorik <igrigorik@google.com>
Date: Fri, 23 Jan 2015 09:33:24 -0800
Message-ID: <CADXXVKqQbDNNo_yxcaj-dbj3Mxowyj5ury7cgqj3yW7fh8ED0A@mail.gmail.com>
To: "Schurman, Eric" <ericsc@amazon.com>
Cc: "public-web-perf@w3.org" <public-web-perf@w3.org>
On Thu, Jan 22, 2015 at 3:00 PM, Schurman, Eric <ericsc@amazon.com> wrote:

> 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.

"deprioritization" has many facets: network priorities and
dependencies, deferred
fetching, execution behaviors, etc. Given the number of various
permutations and requirements, I think we should be focusing on enabling
the smallest number of low-level primitives that enable applications to
implement (and experiment with) these behaviors on their own. In terms of
required pieces:

1) Provide API's for setting/managing fetch-layer settings: e.g. request
priority, dependency trees (in http/2), etc.
2) Separate fetching from processing to allow applications to define own

For (1) we have several threads on whatwg about exposing new APIs on
fetch() and providing a similar mechanism via 'fetch-settings' attribute on
declared elements. For (2), I believe rel=preload is the answer, as it
separates download from processing and yields full control to the
application for how/when fetched resource is applied. In short, I think we
have the necessary pieces in the pipe...

Received on Friday, 23 January 2015 17:34:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:01:27 UTC