I presented to you in a previous article the basics of deferrable views in Angular. Now that you know what you can do with them, let's in the technical details to extract the performance out of them !

How do they work

Under the hood, the deferrable views are a feature of the angular compiler.

When compiling the templates, the Angular compiler extracts all dependencies used within the @defer block into a separate function and generates a number of dynamic imports to load corresponding JS chunks.

@defer {
  <my-heavy-component />
}

function defer_for_block {
  return [ () => import('./my-heavy-component') ]
}

Basically this @defer block results in a single dynamic import that will be executed when the trigger fires.

Nesting blocks

When there are multiple dependencies in a @defer block they end-up in the same import function (except dependencies located inside of nested @defer blocks).

@defer { // Block A
  @if (option === 'a') {
    <heavy-component-a />
  } @else if (option === 'b') {
    <heavy-component-b />
  } @else {
    @defer { // Block B
      <heavy-component-c />
    }
  }
}

function defer_for_blockA {
  return [
    () => import('./heavy-component-a'),
    () => import('./heavy-component-b')
  ]
}

function defer_for_blockB {
  return [
    () => import('./heavy-component-c')
  ]
}

In this scenario, we have 2 @defer blocks resulting in 2 generated lazy-loading functions.

When the trigger for block BlockA is fired, both chunks would be loaded, but only one of the components would be rendered. The third chunk would only be loaded, once we make it into the last @else block.

So, if all of the components are "heavy", you may want to consider wrapping those components into individual @defer blocks (similar to what we have in the last @else block). The same logic would apply if we replace the @if block with a @switch block.

@for or @defer first ?

Now that we know that nesting has implications, let's compare the differences when using an @for block in combination with a @defer block.

First we need to understand the runtime implications of a @defer block. At runtime, a @defer block's content is represented by an embedded view (as if the content was in an <ng-template>). Next look at 2 possibles combinations :

@for (item of items) {
  @defer {
    <my-heavy-component />
  }
}

@defer {
  @for (item of items) {
    <my-heavy-component />
  }
}

In the left example, for each item there will be an embedded view created as a part of @for loop and a nested embedded view created for each @defer block. The number of embedded views would be items.length * 2 and the number of defer block instances would be items.length.

The right example would produce items.length + 1 embedded views and a single defer block instance.

So for the cases above, where the contents of the @for loop doesn't have conditions with different "heavy" components, it would make sense to choose the right example where the @defer is outside of the @for loop.

However, if the contents of the @for loop has some extra logic and involves showing different "heavy" components depending on certain conditions, you may want to choose the left example where @defer is inside of the @for loop to wrap a particular component or a group of components.

Now that you know the implications of the usage:

If you have any other questions on this great new feature, feel free to reach out to me on Twitter !