{"id":23455,"date":"2023-11-15T22:43:13","date_gmt":"2023-11-15T21:43:13","guid":{"rendered":"https:\/\/www.angulararchitects.io\/blog\/how-to-improve-initial-load-performance-with-angular-17s-deferrable-views\/"},"modified":"2025-03-24T20:47:02","modified_gmt":"2025-03-24T19:47:02","slug":"deferrable-views","status":"publish","type":"post","link":"https:\/\/www.angulararchitects.io\/en\/blog\/deferrable-views\/","title":{"rendered":"Improve Initial Load Time with Deferrable Views"},"content":{"rendered":"
\n\t\t\t\n\t\n\t\n\t\t

\n\t\t\tThis is post 4 of 6 in the series “Performance Optimization”<\/em>\t\t<\/p>\n\t\t\t<\/label>\n\n\t\t\t

\n\t\t\t
    \n\t\t\t\t\t\t\t\t\t
  1. Why is Initial Load Performance so Important?<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  2. How to measure Initial Load Performance<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  3. How to use Angular SSR with Hydration<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  4. Improve Initial Load Time with Deferrable Views<\/span><\/li>\n\t\t\t\t\t\t\t\t\t
  5. How to @defer 3rd party dependencies<\/a><\/li>\n\t\t\t\t\t\t\t\t\t
  6. Updated: Guide for Server-Side Rendering (SSR) in Angular<\/a><\/li>\n\t\t\t\t\t\t\t<\/ol>\n\t\t<\/div>\n\t<\/div>\n

    Besides some minor updates concerning Server Side Rendering (including things as making the great new Hydration feature stable, renaming the universal package to @angular\/ssr<\/code> and adding SSR support to the CLI's ng new<\/code> command) the biggest upgrade for us performance enthusiasts<\/strong> in Angular 17<\/em> is definitely the new block template syntax<\/strong> including the defer block<\/strong> feature. By the way, the new template syntax is also beneficial for the runtime performance - we'll cover that topic in another blog post soon \ud83d\ude0f<\/p>\n

    Until Angular 16<\/em> it was a bit complicated to dynamically lazy load (now called defer) components, without having to use the Angular<\/em> router's loadChildren<\/code> (for a module<\/em> or an array of components<\/em>) or loadComponent<\/code> (for just one standalone component<\/em>). Since Angular 13<\/em> we didn't need a ComponentFactoryResolver<\/code> to create the component anymore, but we still had to use a ViewContainerRef<\/code> and something like an async \/ await<\/code> block to dynamically load, create and insert the component into the DOM.<\/p>\n

    With @defer<\/code> we now have an elegant and intuitive option to delay the loading of components<\/strong> until they are needed. This is especially useful for components that are not visible on the initial screen (so-called above-the-fold<\/strong>) of our web app. The @defer<\/code> feature has the largest impact if we can use it for heavy components that include large third party packages like feature-rich tables<\/strong>, charts<\/strong> or some export<\/strong> functionality (e.g. PDF generator), because those packages can then also be deferred and thus excluded from the eagerly loaded main bundle.<\/p>\n

    Why is Initial Load Performance so important?<\/h2>\n

    We recently blogged about Why Initial Load Performance is so important<\/a>, focussing on SSR.
    \nDeferrable Views, also known as @defer<\/code> blocks, are a lightweight innovation to reduce the initial bundle size and thus further improve the Initial Load Performance of our Angular<\/em> app.<\/p>\n

    We also wrote about how to measure the Initial Load Performance<\/a>.
    \nDeferring some of your components should specifically improve First Contentful Paint (FCP)<\/strong>, Largest Contentful Paint (LCP)<\/strong> and even Time to First Byte (TTFB)<\/strong>.
    \nHowever, be careful not to increase the Cumulative Layout Shift (CLS)<\/strong> by deferring components that are visible on the initial above-the-fold screen.
    \nYou can achieve this by using placeholders<\/strong> (see below for @placeholder<\/code> and @loading<\/code>) with fixed width and height properties - just like you'd do for lazy loading images with the help of NgOptimizeImage<\/code>.<\/p>\n

    How to dynamically load components with Angular 13 - 16<\/h2>\n

    In my Performance Workshop<\/strong><\/a> \ud83d\ude80 I always show(ed) how to dynamically load components with Angular 13 - 16<\/em>.<\/p>\n

    Firstly, we need to get a ViewContainerRef<\/code> in the components view template. Since we don't want to create an HTML element, we use an ng-container<\/code>:<\/p>\n

    <ng-container #viewContainer \/><\/code><\/pre>\n
    Important note: Since Angular 15.1.0<\/em> we can use self-closing tags in Angular<\/em> - also for components without content.<\/p>\n
    Secondly, we need to fetch the ViewContainerRef<\/code> via a @ViewChild<\/code> using the template reference #viewContainer<\/code> in the component class:<\/p>\n
    @ViewChild('viewContainer', { read: ViewContainerRef }) viewContainerRef!: ViewContainerRef;<\/code><\/pre>\n
    Thirdly, we can use async \/ await<\/code> to dynamically import a component and insert it into the DOM:<\/p>\n
    async ngAfterViewInit() {\n  const { LazyComponent } = await import('.\/lazy\/lazy.component');\n  const lazyComponentRef = this.viewContainerRef.createComponent(LazyComponent);\n}<\/code><\/pre>\n
    As a result the Angular Compiler<\/em> will create a new chunk for the LazyComponent<\/code> and the app (well, the browser) will load the bundle on demand.<\/p>\n
    While this is still a working approach, it is a bit heavyweight and less powerful than using the new @defer<\/code> syntax.<\/p>\n
    Important note: To fully support deferring our LazyComponent<\/code> must be a standalone component<\/em>.<\/p>\n
    How to dynamically load components with Angular 17's @defer<\/h2>\n
    With Angular 17<\/em> we can use the fancy @defer<\/code> syntax. The syntax is very similar to the new @if<\/code> and much, much easier to use:<\/p>\n
    @defer {\n  <aa-lazy-component \/>\n}<\/code><\/pre>\n
    That's all there is to it \ud83e\udd73 - the Angular Compiler<\/em> will again create a new chunk for the LazyComponent<\/code> and the app (again, the browser) will load the bundle on demand.<\/p>\n
    But that's not the end of the story (nor this post \ud83d\ude09). We can additionally leverage the control of the lazy loading process by using built-in and even our own triggers<\/strong>.<\/p>\n
    Triggers<\/h2>\n
    The @defer<\/code> block in the provided context is used to replace placeholder content with lazily loaded content.<\/p>\n
    Two options for triggering this swap are specified: on<\/code> and when<\/code>.<\/p>\n
    on<\/code><\/h3>\n
    on<\/code> specifies built-in trigger conditions using events like interaction or viewport.<\/p>\n
    @defer (on viewport) {\n  <aa-lazy-component \/>\n}<\/code><\/pre>\n
    A list of on<\/code> events provided in Angular 17<\/em>:<\/p>\n