[Complete] RFC: Deferred Loading

[jessicajaniuk]

Authors: @AndrewKushnir, @clydin, @jessicajaniuk
Area: Angular Framework
Posted: June 14, 2023
Status: Open

The modern web emphasizes delivering a strong user experience during the loading of an application. Metrics like Core Web Vitals quantify this experience, highlighting the performance of the initial load.

One standard and effective technique for optimizing this loading experience is to defer lower priority parts of the UI and focus resources on loading the most critical parts of the page. For example, a page which shows a main video and a list of comments may be optimized to load the video first, and defer loading the code to render the comments until the video is fully buffered and ready to play.

Angular supports lazy loading of parts of the application via the Router (lazy routes). Lazy loading of individual components is achievable via dynamic import() and ngComponentOutlet, but this approach can be complex and error prone.

As a result, we see a lot of potential in introducing an ergonomic, holistic approach to deferred loading in the core framework, that works across both client- and server-side rendering. This RFC proposes a new framework primitive: {#defer}.

A note on the timeline

We're conducting this RFC as a part of our larger efforts around initial rendering and server-side rendering. While we're excited by the ideas presented here, our goal is to gather some early feedback to inform our roadmap, and we may not progress to the implementation phase until other projects have completed. When we do begin implementation, features will land incrementally over time.

What kind of feedback are we looking for?

While we're excited to hear any and all comments on this primitive for deferred loading in Angular, we have additionally called out specific discussion points throughout the RFC for directed feedback. When you leave a comment, be sure to note the open question(s) to which you're responding.

As always, keep our code of conduct in mind. We know that a proposal of this scope significantly impacts Angular and the way you use it in your projects. We appreciate your commitment and investment in this project and ask to keep comments respectful.

Goals

• Make deferred loading in Angular predictable and ergonomic for all developers
• Reduce initial page load time due to smaller initial bundle sizes
  8 Support deferred loading of directives & pipes as well as components
• Introduce new patterns to allow developers to build applications that leverage deferred loading
• Integrate deferred loaded primitive with hydration, so that developers can gain maximum benefits

#defer

Deferred blocks

(Note: This deferred loading primitive makes use of the new block template syntax proposed in the Control Flow RFC -- check out that RFC for more details)

The primitive is represented in template by the following block group: {#defer}...{/defer}. Dependencies (components, directives, etc) referenced within the deferred block are loaded lazily. As a result, deferred blocks are always rendered asynchronously. This includes all dependencies within the deferred block, which would include components, directives, and pipes used within those dependencies.

{#defer}
  <calendar-cmp />
{/defer}

on and when

Conceptually the defer block is a construct which, when triggered, replaces placeholder content with lazily loaded content. Developers have two options for configuring when this swap is triggered: on and when.

when specifies an imperative condition in the form of an expression that returns a boolean. When this expression becomes truthy, the placeholder is swapped with the lazily loaded content (which may be an asynchronous operation if the dependencies need to be fetched).

Crucially, if the when condition switches back to false, the defer block is not reverted back to the placeholder. The swap is a one-time operation. If the content within the block should be conditionally rendered, an if condition can be used within the block itself.

on specifies a declarative trigger condition, usually some kind of event. We will have a series of predefined event triggers (see the Trigger Types section). An example would be on interaction or on viewport.

Multiple event triggers would be supported at once. For example, on interaction, timer(5s) means that the defer block will be triggered if the user interacts with the placeholder, or after 5 seconds.

A more full example is below

{#defer when cond}
  <calendar-cmp />
{/defer}

{#defer on interaction, timer(5s)}
  <calendar-cmp />
{/defer}

Alternatively you could use both when and on together in one statement, and the swap will be triggered if either condition is met.

{#defer when cond; on interaction}
  <calendar-cmp />
{/defer}

:placeholder blocks

By default, defer blocks do not render any content before they're triggered. Using a :placeholder block, developers can specify which content should be shown before the defer block is triggered.

This block may have any content including DOM nodes, components, directives, pipes, etc.

{#defer when cond}
  <calendar-cmp />
{:placeholder minimum 500ms}
  <img src="placeholder.png" />
{/defer}

Note: dependencies of the :placeholder block are eagerly loaded and not deferred.

The :placeholder block is optional, but certain on conditions will require a non-empty placeholder. Additionally, you can specify a minimum condition, which takes a duration (i.e. 50ms). This allows users to specify a minimum duration of time to show the placeholder template before switching away to the next template. This allows users to prevent a fast flickering that could occur if the triggering state was immediate and the response only took a small amount of time.

:loading blocks

The :loading block defines content that should be displayed while the defer block is fetching dependencies in order to render its defer template. Similarly to the :placeholder block above, this block is optional and if not provided, defer blocks will continue to show the :placeholder (if any) until the defer content is loaded.

{#defer}
  <calendar-cmp />
{:loading}
  <div class="loading">Loading the calendar...</div>
{/defer}

Note: similarly to :placeholder, dependencies of the :loading block are eagerly loaded.

When using the :loading block, you can also specify an after condition, which takes a duration (i.e. 50ms). This allows users to specify a minimum duration of time to wait before showing the loading template. The loading template would not be shown if the request to deferred load took less time than the specified duration. This is to prevent layout thrashing caused by a fast flickering between the loading template and defer template.

Similar to the :placeholder, you can specify a minimum condition, which also takes a duration (i.e. 50ms). This allows users to specify a minimum duration of time to show the loading template before switching to the content. This allows users to prevent a similar fast flickering that could occur if the loading only took a small amount of time or a short duration after the after condition finished.

{#defer}
  <calendar-cmp />
{:loading after 100ms; minimum 500ms}
  <div class="loading">Loading the calendar...</div>
{/defer}

:error blocks

The error block represents a UI that should be rendered when deferred loading fails. Similar to the placeholder and loading blocks above, this block is optional and if not provided, defer blocks would not render any content.

{#defer}
  <calendar-cmp />
{:error}
  <p> Failed to load the calendar </p>
  <p><strong>Error:</strong> {{$error.message}}</p>
{/defer}

Note: similarly to :placeholder and :loading, dependencies of the :error block are eagerly loaded.

Along with the error block, a user will have access to the error thrown during the loading process via a $error variable accessible in the error block.

Discussion Question 1B: Do you see the need to be able to observe when the state of a defer block changes via a signal or event?

Resource Prefetching and Content Rendering

There may be a desire to separate the deferred loading action from the content rendering action. For example, users may want to prefetch a set of dependencies in preparation for an anticipated user action, reducing the delay to that deferred block being interactable. In that case, users can optionally provide a prefetch condition to prefetch dependencies before the main trigger. prefetch syntax works similarly to the main defer condition, and accepts when and/or on to declare the trigger.

In this case, when and on associated with defer controls when to render, and prefetch when and prefetch on controls when to fetch the resources. This enables more advanced behaviors, such as letting you start to prefetch resources before a user has actually seen or interacted with a defer block, but might interact with it soon, making the resources available faster.

Just like with on and when with defer, these are one way behaviors. Switching prefetch when to false does not hide the content. Hiding content can be accomplished when composed with if.

{#defer on interaction; prefetch on idle}
  <calendar-cmp />
{/defer}

We plan to take into consideration the current browser configuration and the user's connection speed by looking at the browser's navigator.connection data, NetworkInformation.saveData, and NetworkInformation.effectiveType when supported by the browser. This will ensure we provide the best possible user experience around prefetching.

Timeouts

Defer blocks provide an API for developers to configure timeouts for deferred loading operations, after which the request should be considered failed.

To configure this behavior, timeout can be defined on the {#defer} block, which defines the timeout duration in milliseconds:

{#defer timeout 100ms}
  <calendar-cmp />
{:error}
  ...
{/defer}

Discussion Question 2B: Are there use cases where different deferred blocks in an application should use different timeouts?

Trigger Types

idle

idle would trigger the deferred loading once the browser has reached an idle state. This is the default behavior with a defer block.

interaction

interaction means click, focus, touch and input events (keydown, blur, etc).

immediate

immediate triggers the deferred load immediately, meaning once the client has finished rendering, the defer chunk would then start fetching right away.

timer(x)

timer(x) would trigger after a specified duration.

hover

hover would trigger deferred loading when the mouse has hovered over a trigger area, which could be the placeholder content or a passed in element reference.

viewport

viewport would trigger the deferred block when the specified content enters the viewport using the IntersectionObserver API. This could be the placeholder content or an element reference.

Example #1: deferred loading is triggered when placeholder content becomes visible in a viewport.

{#defer on viewport}
  <calendar-cmp />
{:placeholder}
  Calendar placeholder
{/defer}

Example #2: deferred loading is triggered when another element becomes visible in a viewport using a local ref:

<div #greeting>Hello!</div>

{#defer on viewport(greeting)}
  <greetings-cmp />
{/defer}

These triggers are designed to handle the most common scenarios. If your use case requires a more complex scenario than the predefined trigger list, use when to define your condition.

Discussion Question 3B: Is this list of predefined triggers sufficient to handle the majority of cases that users may have? Can you think of other common trigger types that we didn't account for in this design?

Discussion Question 4B: Can you think of use cases where you would need to change the default trigger behavior globally for all {#defer} blocks in your application?

Nesting

{#defer} blocks can be nested and there are legit use-cases for doing this. For example: you may want to render a big component when it becomes visible in a viewport, but load some inner components once a user clicks a button.

Important note: nesting of defer sections may cause performance issues where components would sequentially load extra resources as Angular progresses with the rendering and discovers more defer boundaries. We plan to provide diagnostics and tooling for developers to help avoid this issue. See "Cascading Requests" section below.

Server Side Rendering Behavior

When rendering an application on the server, defer blocks always render their placeholder (or nothing if a placeholder is not specified). Triggers are ignored on the server.

See the next section for more information on the future plans for integration of defer with server side rendering.

Potential Future Path to Partial Hydration

Our roadmap for server-side rendering includes research into expanding our hydration implementation to support partial hydration - leaving server-side rendered content dehydrated after the initial page load. defer could be extended to integrate such functionality.

With partial hydration enabled, deferred content could be server-rendered and then left dehydrated until triggering conditions are met. We plan on conducting more research in this area and will follow up with a future RFC potentially bringing extra configuration to the defer block that would allow you to configure server rendering and hydration behavior in a more granular way.

Common Pitfalls

Cascading Requests

There are cases where nesting multiple defer blocks may cause cascading requests. An example of this would be when an defer block with an immediate trigger has a nested defer block with another immediate trigger. If it's all within one template, we could easily group those into one request, but in this case in a nested component template, this would not be catchable. We plan to implement extra diagnostics to warn developers about such patterns:

For nested defer blocks within a single template, the compiler can detect those patterns and output a warning to a user. This can also be handled by the Extended Template Diagnostics subsystem.

For nested blocks across multiple components, we can add detection mechanisms to runtime (in dev mode only).

This would also be highlighted in the docs as an anti-pattern (along with other good and bad practices).

Content Projection inside Defer Blocks

Dependencies of the content projected from outside of a component are not deferred when projected into a defer block. If you want to deferred load projected content dependencies, you can wrap that content into {#defer} block (with the necessary conditions) separately.

Wrapping content with no dependencies

If a user writes a {#defer} block, and inside that defer block is only content that has no dependencies (components, directives, pipes, etc) to extract, the defer block actually serves no purpose. We'll want to catch this case and provide an error to the user. The prior case of content projection inside of a defer block is one example. If a user only places DOM inside, and there are no directives applied to any of them, that would be another case. We'll highlight in the docs that this is an unnecessary use of defer blocks. We'll also want to add compile time checks for this to prevent users from making this mistake.

Cumulative Layout Shift (CLS) Risk

When using {#defer} blocks above the fold, if placeholders do not match the exact size of the deferred content that will replace it, it will contribute to the cumulative layout shift of the application's core web vitals. From a strictly CWV perspective, the recommendation is generally that you should only insert content a) out of viewport, or, b) in response to user input.

Frequently Asked Questions

Q: Why is this feature called defer?

We've deferred answering this until later on in the FAQ.

Q: Why is this feature called defer?

The action of what this feature is doing is deferring the loading of something until a certain condition is met after the initial page load. This is a behavior that's similar to the script defer attribute, which loads resources in parallel and executes after the page has been parsed. Lazy loading is loading only when needing to use it. Deferred loading can be used for more than just loading something lazily.

Q: Can I use in a deferred block?

Yes, with the caveat that it is not the only thing inside of the defer block. See the section above on wrapping content with no dependencies for more information.

Q: Can I imperatively trigger deferred loading?

You can use a when expression to trigger the deferred block at any point.

Q: Is there a way to observe when defer blocks are loaded or state has changed?

See discussion question 1B.

Q: Can I define my own triggers?

No, we don't plan on supporting user-defined triggers. The current set of declarative triggers will be tightly integrated into the framework. If you have ideas for new triggers that would be useful in your applications, we'd love to hear them (see discussion question 4B).

You can also use a when expression to completely customize the triggering logic.

[rogerg93]

Checked before the end of ng-conf keynote :D So awesome!

[TheLarkInn]

As a result, we see a lot of potential in introducing an ergonomic, holistic approach to deferred loading in the core framework, that works across both client- and server-side rendering. This RFC proposes a new framework primitive: {#defer}.

@jessicajaniuk is this feature just going to be using import() primitives under the hood? I think this is a great idea and lets bundlers/tools do more heavy lifting but should have some clarity around this information. Great RFC.

[jessicajaniuk]

It'll be using dynamic import under the hood, but it'll also be integrated with the bundler. So the dynamic import will likely be a single dynamic import with all the dependencies in it from that defer block rather than N number of dynamic imports.

[robertIsaac]

1B: Signal
2B: yes, some of them will be expected to load a full library (ngx-markdown is what I'm thinking, or a chart) that's why it's deferred and will take a lot of time to be fully loaded, while others will be just another component that is not important (comments for example like you said) which will take a short time (but of course will then trigger HTTP call to fetch the comments, but I think that won't make it timeout if the HTTP call took longer, will it?)
3B: I don't think of something else
4B: yes, to change all of them to immediate or timer(1s) instead of idle, I'd need to test my whole application performance to choose the right one for me (and the difference between immediate and idle is confusing, if you can elaborate it will be great)

[jessicajaniuk]

idle would be based on the idle detection APIs in the browser and would wait to defer load until the browser reports that it's fully idle, whereas immediate would not wait for that and immediately trigger the deferred loading upon being seen during the render. Essentially the benefit there is to remove that from the main bundle into a separate one while still making it available quickly to the user.

[robertIsaac]

@jessicajaniuk thank you for answering, would that require IdleDetector permission for all applications using defer? if yes then what's the alternative if the user rejected/ignored the permission request? will it will be immediate?

[alxhub]

I don't believe requestIdleCallback requires any special permission to use.

[robertIsaac]

@alxhub I think she means https://developer.mozilla.org/en-US/docs/Web/API/Idle_Detection_API, and it requires a permission

[clydin]

The idle trigger will be based on the idle state of the browser not the user. This will most likely be achieved through the use of requestIdleCallback combined with a small "polyfill" based on setTimeout for browsers without support for that API.

[alcfeoh]

Would this work only with standalone components and features? That would be my guess since we could lazy-load anything using defer.

[jessicajaniuk]

It will be compatible with both standalone components and ngmodules.

[alcfeoh]

But that ng-module should be set up for lazy-loading, meaning it would not be referenced in the AppModule, otherwise, it would be part of the main bundle, right?

[alxhub]

It's a complicated topic, actually, and depends on the specific scenario, the application bundler being used, and (possibly) how a library was bundled & shipped. Generally speaking, the most optimal results will be with standalone components, and NgModules in the same application should work well as well. NgModules from 3rd party libraries may cause issues depending on the bundler.

[mkloeppner]

@alcfeoh @alxhub From my experience at least with webpack yes, as soon as you have a static import and I guess that's true for all bundlers. (Code that implementation is been used must be available).

Though if you have a dynamic import no.

The question is would defer also convert static imports to dynamic inside the app module for services, directives or modules that are only used by deferred temples?

I guess it won't since I guess if it's imported in the app module it's been used and I would not expect defer to rewrite my custom app logic.

@jessicajaniuk

[imaksp]

@alxhub I think to simplify this should only be supported in standalone components, & in new projects standalone should be the default. I migrated 2-3 apps to standalone & it has reduced lot of boilerplate code & lazy loading of route became very simple & easy to understand. so I see nothing wrong in making it default in v17.

[e-oz]

That will move Angular so much forward! It opens a lot of opportunities that were not possible before.

Discussion Question 1B: Do you see the need to be able to observe when the state of a defer block changes via a signal or event?

If it will be possible to catch using ViewChild() set..., then no. Otherwise: sure!

---

Groundbreaking move!

[KevTale]

That's huge news! I'm super hyped!

My question is, when would the {:error} block triggers exactly? How can a component fails to render?

[JeanMeche]

When an error is thrown while executing the render function ?

[jessicajaniuk]

This would be when something fails with the component lazy loading. Think about when somehow the connection goes offline or something similar.

[KevTale]

Gotcha, thanks @jessicajaniuk!

Also, I'm not sure to understand the nuance between idle and immediate. You said the former makes the defer triggers once the browser has reached an idle state and the latter when the browser has finished rendering.
What's the difference between a browser being in an idle state and a browser that has finished rendering?

[jessicajaniuk]

The browser reports idle once all actions have finished. So the page would render, there may be a data request in progress. Other actions may be occurring. So depending on your connection, that could be seconds later. Immediate would fire the moment that block rendered. So it wouldn't wait for your browser to finish activity. It would immediately start fetching that moment, regardless of remaining tasks. Hopefully this clarifies it for you.

Check out the requestIdleCallback for more information on how that API works.

[mkloeppner-lotto24]

Discussion Question 1B: Yes in order to to control the order of deferred loads.

Discussion Question 3B:
Great feature, one question though on the chunks specifically and this as a feature to allow developers improving performance.

Developers are looking for optimising Google Web Vitals https://web.dev/vitals/ and this could be a tool to address the LCP of an application by reducing main bundle size.

However, how is the order of multiple deferred blocks in terms of the download process of the chunks?
Our experience shows that too many concurrent downloads (higher amount of chunks) can slow down an application significantly on mobile networks and delay JavaScript evaluation and rendering is compared to loading chunk by chunk in sequence.

Imagine we have 6 different deferred templates above the fold using different libraries => creating different chunks. We want to control the deferred templates and prioritise the load of one above the other.

Is there any control about the bundling and order of deferred blocks planned? I am also on ng-conf2023 so happy to answer or discuss details in person :)

[ajitzero]

This looks great! It reminds me of Astro's client directives like client:idle (default), client:visible (defer on viewport) & client:media={string} (not mentioned here).

Can we consider adding support for a trigger for media? Suggested categories would be:

• Type:
  • screen (default)
  • print. Example: {#defer on media.print } - Alternate syntax to avoid conflicts with the example below.
• Screen CSS media breakpoints.
  • Example 1: {#defer on media="(max-width: 50em)" } - Hard-coded value.
  • Example 2: {#defer on [media]="BreakpointEnum.Desktop" } - String-based enum.

[KhaledGabr]

I second that, certain elements in the page can be displayed for a specific media size only, so they may not be loaded at all until the screen gets resized.

Another scenario that comes to my mind is that certain components may be left dehydrated after server side rendering because they are display only at specific screen size but interactive on others (ex: top menu that requires JavaScript to be loaded only on the phone)

[red-0ne]

Having this for container query conditions would be awesome too.

[ajitzero]

Regarding the semantics of on, how are we supposed to read the code?

when is appropriately named since it defers loadings when some condition is truthy, and it is strictly a one-time swap, as mentioned above. So, this reads out as-is in English.

But on has slightly inconsistent naming usage: {#defer on viewport} implies the loading is deferred when "on
[entering] viewport", i.e., when the component comes into the viewport, it instead means the component will be deferred until it comes into the viewport.

I don't know if until should be added for this case, but maybe the syntax could be clarified further for on? Apart from replacing on with until, I do not have a reasonable suggestion here.

Edit: I suggest these variants:

• {#defer when condition} - makes sense as-is.
• {#defer until condition} - instead of on.
• {#load on condition} - deferred by default, fetching/loading on condition.

[AndrewKushnir]

The thinking behind on is to illustrate that there is a certain event that should occur to trigger the loading (thus the on as a prefix, similar to DOM event names). The general pattern is {#defer [trigger condition 1];[trigger condition 2];...}, so for each trigger condition having on as a prefix looks reasonable. However I do agree that without this context, {#defer until interaction} reads better. We'll discuss this further and share an update.

[ajitzero]

Yes, this reasoning makes a lot of sense, but now my issue has changed places 😅

I now suggest replacing #defer with #load, which makes it read like "load the component on interaction".

[KhaledGabr]

Thank you for this RFC, Anything that improves web core vital is always appreciated.

I am wondering how would dynamically created components be handled?
It will be handy to pass Trigger Types described above to the createComponent() function to control how and when the component gets loaded.

Any thoughts ?

[AndrewKushnir]

I am wondering how would dynamically created components be handled?
It will be handy to pass Trigger Types described above to the createComponent() function to control how and when the component gets loaded.

There are no changes to the createComponent, ViewContainerRef.createComponent and NgComponentOutlet are planned in a context of this RFC. Those APIs are invoked when component's code is already downloaded and available on the client, so passing triggers would be too late in the process.

[KhaledGabr]

Got it, so In this case, I would use import() when I want to download a component (on browser idle for example) before calling the createComponent() function to defer the downloading of that component.

However, that process might be a bit complex and error prone though, since developers will need to implement the triggering logic to defer the import() themselves.

Also, if it happens and the createComponent() was called before the component is available, the developer will need to import() it right then and there to download it and then create it.

[derekkite]

I can think of two triggers. One waits for the data to show up. Instead of delaying the rendering, it would delay the fetching of the components.

A second is a depends on trigger, controlling the order that components are loaded and rendered.

[AndrewKushnir]

I can think of two triggers. One waits for the data to show up. Instead of delaying the rendering, it would delay the fetching of the components.

Could you please provide an example of how this trigger would look like in a template and how that would be integrated with components from the {#defer} block?

A second is a depends on trigger, controlling the order that components are loaded and rendered.

The {#defer} block could be extended in the future to support the notion of priority (it was also brought up in #50716 (comment)). We've discussed this topic with the team before publishing this RFC, but decided that it requires more research. Once the initial version of the {#defer} block is available, we'll also start collecting the feedback from developers that enabled it in their apps. The combination of the research results and the feedback would help us to make a final decision on whether adding a "rendering" priority is the right configuration option for this primitive and if so, how it should look like.

[KevTale]

What would happens in that scenario?

<p>hello world!</p>

{#defer}
  <calendar-cmp />
{/defer}

{#defer}
  <other-cmp />
{/defer}

When the browser is idle, it will fetch the calendar then when calendar chunk has finished downloading it will fetch other-cmp?
Or does it load in parallel?

[AndrewKushnir]

I think the desired behavior in this scenario would be to start downloading both chunks in parallel. We'll do more exploration during the implementation phase to see how we can support this scenario best.

[NateRadebaugh]

And if in parallel should they be batched or separate chunks? Aka if one is loading, should all be loading?

[AndrewKushnir]

And if in parallel should they be batched or separate chunks? Aka if one is loading, should all be loading?

The code for <calendar-cmp /> and <other-cmp /> will end up in separate chunks. The loading of both chunks would happen in parallel and once a chunk is loaded, the rendering would be performed for a corresponding {#defer} block.

[luishcastroc]

One of the things that I didn’t see and should go in parallel (I believe) with the built-in control for consistency is the fact that the syntax is {#defer} I believe this should go hand by hand with what the built-in control syntax ends up adopting (example [#if ] ).

[alxhub]

We'll definitely keep them unified, absolutely.

[james-schwartzkopf]

Wrapping content with no dependencies

If a user writes a {#defer} block, and inside that defer block is only content that has no dependencies (components, directives, pipes, etc) to extract, the defer block actually serves no purpose.

So I guess this isn't meant to work with lazy loading data, only code? It seems like it would be confusing not to work with both.

Also, what about animations, will placeholder etc support out animations?

[alxhub]

when conditions can be used to trigger defer when data becomes available.

[james-schwartzkopf]

But not if the contents are just HTML.

And that case would be easily handled by an ngIf anyway. I'd be more interested in a defer that waits till visible, then loads data and makes it available to the template that could just be non lazy content.

[alxhub]

But not if the contents are just HTML.

In that case, there's nothing really that you're deferring - no lazy loading of dependencies, no component/directive instantiation cost, no child templates. It'd be indistinguishable from {#if data} (which would be the preferred way of conditional rendering based on data).

[james-schwartzkopf]

The difference from the if would be the on cases. If defer doesn't work with data, it would be nice if the on triggers where made available outside of defer.

I just think it would be nicer if we had one solution for both cases.

[zygarios]

Great, innovative functionality. Good job AngularTeam.

I just have a question about this part:

"Wrapping content with no dependencies
If a user writes a {#defer} block, and inside that defer block is only content that has no dependencies (components, directives, pipes, etc.) to extract, the defer block actually serves no purpose."

Aside from performance considerations, I see a lot of potential in cases where there are no dependencies. Instead of writing a whole script using IntersectionObserver to load a DOM structure when it becomes visible, I would prefer to use a simple "defer" with an "on viewport" option to nicely display an HTML fragment with some animation. I'm not insisting, and I understand that wasn't the purpose of adding this feature. I just feel that even in these simpler cases, I might want to take advantage of it.

Warm regards to everyone, and thank you so much Angular for making it a pleasure to work with you every day :)

[yjaaidi]

The Testing Story

Given that testing is mainly achieved using JIT, what will be the behavior in that case?
I guess that defer will be a "no-op", right?
If that's the case, then there is no way to make a defer render :loading / :placeholder / :error blocks in a test, right?

It would be nice to have a testing API that allows us to manually control the state of the defer blocks. (e.g. DeferTestingController.flushPendingDefers())
IMO, a coarse-grained API that allows us to control all defer blocks is fine to start with.
The next challenge though is to control a specific defer block as we will need to reference somehow (maybe a testing id?).

[jessicajaniuk]

You are correct in that in JIT mode defer would be a no-op. We haven't thought much about what the testing APIs would look like yet, but an ability to provide that level of control does make sense. We'll gather more feedback on what people would like.

[eduardoRoth]

Discussion Question 3B: Is this list of predefined triggers sufficient to handle the majority of cases that users may have? Can you think of other common trigger types that we didn't account for in this design?

I think that click (when an element is clicked) would be another trigger for loading a deferred block, like quickly loading a modal, a tooltip, or maybe prefetching another block of content for next clicks.

[eduardoRoth]

<a #detailsLink>View details</a>

{#defer on click(detailsLink)}
<modal>
  This is the details view
</modal>
{/defer}

[eduardoRoth]

We could benefit of the {:loading} and {:placeholder} so we could defer complex components yet show some elements when the user clicks on the element.

[AndrewKushnir]

It would be covered by the on interaction condition: interaction includes click, focus, touch and input events (keydown, blur, etc)). For example:

<a #detailsLink>View details</a>

{#defer on interaction(detailsLink)}
  <modal>This is the details view</modal>
{/defer}

[mlc-mlapis]

Great work. 🥇

1B: Yes. It would help manage and control the applications.
2B: Timeouts could also vary if the resource connections are different.
3B: No other triggers. The suggested ones are enough.
4B: Global triggers config can be helpful in optimization, especially when combined with the possibility to specify several connection types.

[samuelfernandez]

Impact on Core Web Vitals, especially CLS

Just a thought, incremental loading of deferred components might have a negative impact on web vitals, especially Cumulative Layout Shift (CLS). Best benefits are achieved in combination with SSR, as the goals mention. I feel that alongside this new tooling, guidelines and best practices should also be provided to avoid common issues. How to do proper skeleton loading would be great with real examples.

Reference: https://stackoverflow.com/questions/66843879/react-loadable-components-increase-cumulative-layout-shift-cls

[jessicajaniuk]

Yes, absolutely. We've mentioned that in this RFC and have had conversations with Chrome Aurora about best practices. We'll be putting effort into the documentation around this exact concern.

[samuelfernandez]

Thanks, haven't see that in the first read 😄

[samuelfernandez]

Caching with Service Worker

From the several techniques for deferred loading mentioned in the RFC, I assume that they are happening in the main thread. Since in many cases the goal is immediate interaction, using Service Workers would help. Qwik does so by eagerly caching those scripts with a SW, so that when the main thread needs them there are already available, not waiting to be downloaded. This could be run in parallel while the main thread renders, no need to wait until idle or visible.

Are there any plans on providing a combined solution that could integrate well with SW for pre-fetching?

Reference: https://qwik.builder.io/docs/advanced/speculative-module-fetching/

[jessicajaniuk]

We've discussed prefetching a bit and even speculative prefetching, but not in conjunction with a service worker. If we were to implement this sort of feature, it would be a future addition rather than part of the initial release.

[samuelfernandez]

Thanks for the quick reply @jessicajaniuk, and for thinking of it for the future. Even if not part of the initial release, do you think that the build process could emit a sort of manifest or the metadata for all chunks so that other implementers could provide a custom SW solution in the meantime?

Related to: https://angular.io/guide/service-worker-intro#service-workers-in-angular

[jessicajaniuk]

We hadn't thought about this yet, but it's possible. We'll have to assess based on need and see what we can do here. TBD.

[samuelfernandez]

Lazy data loading, async providers

Lazy loading components is great, but in many cases they need data along, one cannot live without the other. Questions:

• How do you envision the interaction between data and component lazy loading in an application? If the lazy loaded component would load its own data before a full render, we'd lose some of the benefits of :placeholder and friends. Alternatively, if using when network calls would be parallel, losing some of the benefits.

  • Would it be possible that prefetching is triggered as soon as #defer block is present, use a when condition fetching for data in parallel, and then render when the component and data are ready?
  • Could when accept a promise or observable as a condition?
  • Could the framework use the error template if either the data or the component loading fails?

• Deferring rendering makes it async, so the limitation explained by @alxhub here asynchronous providers #23279 (comment) will be overcome. That could open the door to many new cool things. For example, load data alongside a defer block and use DI to provide it to the inner component, similar to what is already possible when doing manual lazy loading with component outlet. Would it be possible to have for example a new injector input in the #defer block? Reference: https://www.npmjs.com/package/@nx-squeezer/ngx-async-injector

[jessicajaniuk]

@samuelfernandez For your first point and