Re: [w3c/webcomponents] Lazy Custom Element Definitions (#782)

I'm not for or against this, but I wanted to describe a potential pitfall:

This feature can cause a loading-pyramid: component A renders elements B and C into DOM. A this point, components B and C begin to load. Component B uses components D and E and component C uses F and G. Once B loads, then the browser can start loading D and E. Once C has loaded, then the browser can load F and G.

In contrast, with well-planned route-based loading, when the user lands on a page that uses the top-level A component, the page can go and load A, B, C, D, E, F, and G all in one request at the same time (f.e. inside the same bundle), and thus the experience will load more quickly.

This might be something to consider as a user of a new lazy feature, especially because using native ES modules would make it easy to do this, and composing many components together the DOM tree could get many levels deep, causing many HTTP calls instead of one for a planned route.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/782#issuecomment-562364883