Use automatic migration to make your angular codebase use lazy-loaded routes. Or follow a manual step-by-step migration, if needed.
Lazy loading is a pattern in Angular that allows you to load feature modules on demand, rather than loading the entire application upfront.
It significantly improves the initial load time of an application, especially for large applications, as the browser only downloads the necessary code for the initially requested route. This optimization technique enhances user experience and overall application performance.
You can manually implement lazy loading by configuring routes to use the loadComponent
property instead of component, which utilizes dynamic imports to fetch modules when needed.
Angular also provides an automated migration tool that helps convert eagerly loaded routes to lazy-loaded routes. This migration schematic, invoked using ng generate @angular/core:route-lazy-loading
, analyzes your routing configuration and transforms it to leverage lazy loading.
[00:00] Angular has introduced lazy loaded routes quite a long time ago, but only recently it became possible to migrate eagerly loaded components into lazy loaded components automatically. However, there is one caveat. If this component is not standalone, which means it [00:20] is a part of at least 1 ng module, then this ng module is doing eager imports anyway. So automatic migration might make sense only in case of standalone components. Here, I am on the first branch, which includes components which are not yet standalone. If we take a look at the employee [00:39] listing component, we can see that this is not yet standalone. So let's run the migration. That would be NG generate, and here, again, angular slash core, and the name of the migration is root lazy loading. Right now, I have only a few standalone [00:59] components, and that is actually 1, and that is the benefit listing component. This is the one that is explicitly standalone. So let's run the migration. Route lazy loading, let's apply it for the entire application. And we can see here in the output that there is [01:19] only 2 routes being updated and 12 routes that are skipped. And here we get a nice explanation of why a certain component was not migrated. Certainly, this is because they were not marked as standalone. So let's now see how did these get migrated. [01:39] So this is going to be benefits routing module. And let me open the git diff, also do a horizontal split over here. So here we can see that the component before used to be imported eagerly, and it was just put within the root definition [01:58] here under the component property. After the migration, we can see that the static import is gone. And as a replacement, there is a dynamic import coming straight from the ECMA script specification, and also that the component property has been replaced by the load component [02:18] property. We can also see that the import is using a relative path to a proper directory with a proper file, and here within a module. Now know that this is not an NG module, but an ECMA script module. So essentially, a JavaScript file. And from this file, [02:38] we're just importing one thing that have been exported. As we can see, TypeScript is also allowing us to jump straight to the file. Generally, we are walking into the thing that is explicitly exported over here. Now everything works correctly as we can see here on the right hand side. [02:58] However, the problem is that we would like more components to be migrated. And for this reason, let me quickly revert to the branch where all components are standalone. And let me quickly reload the application. And yep, we're up and running. So let's again run the ng generate angular core root [03:18] lazy loading. And what we can see now is that number of updated routes is 14, and number of skipped routes is 0 since all of our components, which are defined within any means of routing, are marked as stand alone. So what we can see over here in the employees routing is that [03:38] whatever was the route and whatever was the component, whether it was within routes, within for child, for routes, provide routes, provide router, any type of routing configuration, they are being reconfigured to be loaded dynamically. Now what is important is that if we walk back to our console, [03:58] we can see there is quite a lot of these chunks being created. So let's load our application again, and we will see that there is quite a lot of various chunks that have been extracted away. So for instance, the SRC app, these are basically names of the directories, [04:18] projects. And within the projects directory, I have a projects listing directory again, and project listing component JS. And finally, the browser is going to execute the JS files. So we have quite a lot of these files over here. So let's also open the network tab over [04:38] here. So let's walk into the home tab of our application, and we are filtering only the JavaScript files. Now after I clear all the network log and just move along various other tabs that we've got here, the offices, the projects, employees, or benefits, [04:58] we can see that 1 by 1, the lazy chunks that we have listed over here are being explicitly and separately loaded into the browser. So the whole point behind the root lazy loading migration is to reduce the time of the initial page load. And [05:18] thanks to the fact that smaller chunks are being extracted, the main bundle is smaller and, hence, it's loaded faster. So metrics such as largest Contentful Paint will be improved.