Re: [whatwg] Preloading and deferred loading of scripts and other resources

On Thu, Sep 11, 2014 at 7:55 PM, Ryosuke Niwa <rniwa@apple.com> wrote:

> On Sep 8, 2014, at 10:54 PM, Ilya Grigorik <igrigorik@gmail.com> wrote:
>
> > On Mon, Sep 8, 2014 at 7:59 PM, Ian Hickson <ian@hixie.ch> wrote:
> >
> >>> The platform is missing a lower-level primitive (declarative and
> >>> imperative) that is able to explain resource loading with the same
> >>> expressive power as requests initiated by the browser itself.
> >>
> >> That isn't a problem.
> >
> > I don't follow. To me that *is* the core problem that we should solve
> first
> > and ship as soon as possible: if we keep the surface area low, we can
> ship
> > it quickly and let developers experiment and move the platform forward.
> > Adding more layers of higher-level APIs only slows the deployment
> process.
>
> What problem(s) are those developers going to solve with such a low level
> API
> other than the use cases A through Z listed here?


For one, its restricted to <script>, <link>, <style>, <video>, <img>,
<object>, <iframe>, <audio>.

My app is fetching JSON blobs to construct the DOM: there is no way for me
to upgrade a JSON fetch to high priority (XHR is low priority compared to
other elements and requires JS execution); there is no way for me get the
preloader to initiate this fetch. Replace "JSON blob" with "texture pack
for a WebGL app", fancy delta-diff format applicable to my content, or <any
other format>.

To be clear, this is not an argument against providing "needs" and
"load-policy". I'm just pointing out that we (a) need a generic,
declarative fetch (rel=preload) mechanism that is content-type agnostic and
is able to express all the necessary transport options (transport priority,
transport dependencies, etc), and (b) this mechanism should not be coupled
to other primitives that are being proposed here.

(I think we're in agreement here, just repeating as a sanity check)


> > To be clear, I'm not against the core premise of unifying various import
> > mechanisms, but to me that's a secondary goal -- good housekeeping, but
> not
> > the problem that the actual web developers (not implementers) are
> actually
> > up against today. And, at least personally, I think we should prioritize
> > developer needs over implementers. That said, I don't think we're
> actually
> > that far apart…
>
> What are problems Web developers actually up against today?
>
> Not having a low-level network API, on its own, isn’t a problem.
> Please give us a concrete real world use case for which the proposed API
> doesn’t work.
>

Any sufficiently large web application has at least one perf-crippled
attempt at a "smarter resource loader". All of them start with good
intentions and sound observation that browser defaults are sometimes at
odds with app priorities, and all of them end up realizing that (a) XHR is
only reasonable game in town, (b) XHR does not expose the necessary fetch
primitives (prioritization being the biggest one), and (c) XHR hurts their
on first-load performance due to loss of preloader processing.

Browsers fall into similar traps. Our (Chrome) experience with
rel=subresource is a good illustration:
https://code.google.com/p/chromium/issues/detail?id=312327 - simple on the
surface, and hard to get right in practice.

A longer rant on related topic(s):
https://www.igvita.com/2014/10/02/extensible-web-resource-loading-manifesto/

On Sep 13, 2014, at 2:02 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
> > On Sep 8, 2014, at 1:33 PM, Ian Hickson <ian@hixie.ch> wrote:
> >
> > I haven't discussed in detail with my colleagues but my impression is
> that we're quite concerned about the number of load policy options and the
> complexity they introduce.
> >
> > I'm not certain if there is a value in having a load policy for "fetch
> when needed" since that could be achieved by inserting an
> script/style/etc... element when needed.  Are there any use cases for
> having script/style/etc... elements that before they start fetching
> respective sub resources?
>

Agreed. Also, we tried to define a similar concept ("postpone") in Resource
Priorities [1], but that didn't get far because "when needed" is app
specific.  Further, even definitions like "when it comes into viewport"
were contentious because they are not universal best practices - e.g. you
probably want to initiate fetches well before an asset comes into a
viewport to have it ready ahead of time (e.g. app should start prefetching
resources when said resources are X screens away); lazy fetching can be an
anti-pattern on mobile (energy use concerns: we want apps to prefetch and
bundle requests); and so on.

[1]
https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.html


> > It also appears that "apply when needed" can also be achieved by
> inserting link[rel=preload] first and later inserting an element of the
> appreciate type since the resource would have been cached by the browser at
> that point in practice.
>

Agreed. However, note that there are some caching/matching gotchas that
need to be considered here:
http://w3c.github.io/resource-hints/#matching-hint-responses-with-requests

----

With above in mind, a few thoughts for how to move forward:

- rel=preload deserves a *lot* more than a paragraph...
- rel=preload has high functional overlap with pre{connect, render}
processing models.
- rel=preload processing model itself has a non-trivial amount of edge
cases and behaviors to consider
- Resource Hints is attempting to tackle this problem (within the webperf
group):
--- http://w3c.github.io/resource-hints/
--- http://w3c.github.io/resource-hints/#use-cases

(a) I'd love to hear feedback on above proposal, and I think we should
separate out rel=preload from what we're discussing here.

Above proposal does not cover all of the use cases outlined in this
discussion, but it does provide a few core primitives that resolves some of
them. Further, I'd love to see concrete proposals and language for:

- "loadsettings": how does it look, what options are available, etc?
- How do I extract a fetch object/stream out of an element? What's the
shape of the API, etc?

We need concrete proposals on the table for both of the above.

Last but not least, I'm skeptical of "fetch/apply when needed" as a
generic+automated concept. Yes, we can declare dependency trees between
resources, but I'm convinced that "when needed" is something that we can
automatically infer by viewport-based heuristics, or some such. Perhaps,
instead, we should rely on explicit signals? I.e. you declare a dependency
tree of "inert" resources and those resources are only downloaded when an
explicit signal is sent by the app?

ig

Received on Wednesday, 8 October 2014 01:51:42 UTC