Angular lazy loading retro: Module ➡ Component ➡ Deferrable View

Angular 17 released Deferrable Views🔥 While Angular docs excellently covers what Deferrable Views are and why they are beneficial, here I’d like to take a look back at module & component lazy loading and tie that together with deferrable views (a part of component’s template).

Enterprise apps should be split into Feature modules

The correlation between the size of the build output bundle and the Time to First Bite (TTFB) is obvious. A larger bundle takes longer to load, impacting the user experience (try to put ALL in the root module and check the bundle size😀). To counteract this, we distribute code across modules, resulting in smaller, more manageable output bundles. Just a common practice of code organization (nothing Angular specific).

Module ➡ Component ➡ Deferrable View

With the introduction of standalone components, we do the same – distribute code into components. The module is a container for components, directives, and pipes. So, lazy loading of standalone components was a step in reducing that initial bundle.

Angular’s innovation doesn’t stop at lazy loading components; it extends to deferrable views. By enabling the loading of specific parts of a component’s template on demand, Angular provides developers with the tools🗡 for even more granular control, further refining the user experience.

Triggering Deferrable Views

Angular offers multiple options to trigger the loading of deferrable views. Loading on idle (default), hovering, or based on user interactions such as clicks or keydown events makes templates more dynamic and interactive. These options not only enhance the user experience but also allow developers to tailor the loading behavior to suit specific use cases. Check Angular docs for samples👋