Re: [w3ctag/design-reviews] <link> rel="modulepreload" (#213)

@cynthia and I looked at this in a breakout at the TAG face-to-face in Reykjavík.

-----

I think the thing that's bothering us the most is the optionality of the dependency loading.  It seems like the spec should either define one behavior or the other rather than allowing implementations to do either.  Making it optional means that authors will have to list all their dependencies if they want them to all preload.

It's not clear to me what the argument against loading dependencies is.  Is it simply a question of value to developers (and users, for better performance) versus browser implementor convenience?  Or is there something deeper that makes the dependency loading complex?

The example shows a very long list of `<link rel=modulepreload>` elements.  This also seems problematic in that it's a barrier to optimization; it's a very long list that's likely to be identically included into many different pages on a site.  It will then have to be parsed and processed each time without any benefit of caching, whereas if only the toplevel module includes were `modulepreload`ed the browser might have more opportunities to remember the preloading work it does for one page to speed up the loading of another page.

-----

From the earlier discussions it seems like there are two future feature requests that we don't need to hold up this review for, but that we should note:
* recursive fetching for `preload` of other resource types
* integration of recursive fetching into fetch or a higher-level fetch-like API

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/213#issuecomment-494788291