Use route-based lazy loading with loadChildren so feature modules are fetched only when a user navigates to them. Keep the root module lean, move feature routes into each module, and let Angular load the code dynamically at runtime. This reduces the initial bundle, improves load time, and avoids forcing users to download code they may never open.
How Angular lazy loading changes feature-module delivery
Lazy loading is not just a performance trick, it changes when code enters the browser and how you structure the app around route boundaries. Feature modules should own their own routes, while the root module stays focused on shell-level concerns such as layout, authentication flow, and cross-cutting services. That separation keeps the initial payload small and makes route activation the trigger for loading.
In practice, the key decision is whether a feature is truly optional at first paint. If a screen is not needed for every session, it belongs behind a lazy route. If it is part of the app’s always-on entry path, loading it eagerly may be simpler and sometimes faster because it avoids an extra network round trip.
Lazy loading also affects maintainability. When routing lives inside the feature module, each team can evolve its own module boundary without adding more imports to the root application. That reduces coupling, but it also means you need to be disciplined about shared dependencies so common UI pieces and services do not get duplicated across chunks.
Route configuration and module boundaries that make lazy loading work
Angular teams should define feature entry points with route configuration that points to the module, not the component. The standard pattern is to use Angular’s lazy-loading route guidance and keep the feature module’s internal routing self-contained so the app router only needs to know the path to that module.
That design matters because lazy loading only works cleanly when the module boundary is meaningful. A feature module should declare the components, routes, and any feature-specific dependencies it needs, while shared modules should hold reusable UI and pipes that many features consume. If shared code is placed carelessly, you can end up with hard-to-reason chunk boundaries or accidental eager imports.
Teams should also check how guards, resolvers, and preloading interact with route loading. A guard can prevent the module from loading until access is confirmed, but a guard that imports feature code too early can defeat the purpose. Preloading can improve perceived speed for likely-next routes, but it should be selective rather than blanket loading every chunk after startup.
- Keep feature routing inside the feature module.
- Import the module through the router, not through the root module.
- Place only truly shared code in shared modules.
- Review guard and resolver imports so they do not pull lazy code into the initial bundle.
- Use preloading only where user behaviour justifies it.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS Control 4 — Secure Configuration of Enterprise Assets and Software | Lazy loading is a software delivery and configuration choice that affects application footprint. |
| Recommendation — Reduce initial application footprint by loading feature code only when the route is visited. | ||
| NIST CSF 2.0 | PR.AC-3 — Remote Access is Managed | Route-based loading is a controlled access pattern for application features and pages. |
| PR.IP-1 — Baseline Configuration | Lazy loading depends on a deliberate application baseline and routing configuration. | |
| Recommendation — Limit feature exposure until navigation reaches the authorized route. Establish a routing baseline that keeps the shell lean and the feature modules isolated. | ||
Practitioner Guidance
What to prioritise: Start by mapping the app into route-level features and deciding which ones are genuinely non-essential at startup. The right boundary is usually the one that matches user journeys, not the one that happens to match a folder structure.
What to verify: Confirm that the root bundle shrinks after the change and that the feature code is fetched only on navigation. Also verify that shared dependencies are not being copied into multiple lazy chunks, because that can erode the gain even when routing is correct.
Common mistake: Teams often lazy-load a module but leave heavy imports in the shell, which makes the app feel unchanged. Another common error is over-fragmenting the application, where too many tiny chunks create more latency and orchestration overhead than the bundle savings justify.
Practitioner takeaway: Treat lazy loading as a boundary design exercise, not a syntax exercise; the best implementation is the one that reduces initial cost without making routing, sharing, or ownership harder to reason about.
Related resources from NHI Mgmt Group
- How should teams implement RBAC in an Angular app without relying on the UI alone?
- How should security teams implement relationship-based access control for dynamic feature flags in React?
- How should teams implement CSRF protection in Angular applications that use cookie-based sessions?
- How should engineering teams implement feature flags without creating unnecessary complexity?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
