There's a pattern I've been seeing more frequently across Angular codebases since standalone components became mainstream.
A team migrates away from NgModules. They discover loadComponent. It's simpler, requires less boilerplate, and feels aligned with where Angular is heading. So they start replacing loadChildren calls across the routing configuration — one by one, sometimes all at once.
The build passes. The application behaves exactly as before. Bundle reports may even suggest the migration was a success.
The problem is that routing decisions are judged by what happens immediately after deployment. Architectural decisions are judged six months later.
I've reviewed migrations where every loadChildren route was replaced with loadComponent in a single PR. The application kept working. Six months later the route structure no longer reflected the application's feature boundaries. Ownership became harder to understand. Shared concerns started leaking across routes. The routing configuration became flatter — but not simpler. One of those reviews turned into a two-sprint refactor that the team hadn't budgeted for.
Angular 19 made standalone the default. New projects no longer generate NgModules, which means loadComponent is now the first lazy-loading API many developers encounter. That makes the distinction between these two APIs more important than ever — not less.
This article is not about which API is newer. It's about understanding the architectural boundary each one creates, and why treating them as interchangeable is a mistake that compounds quietly over time.
What Angular Actually Says
The . Measure the before and after. If you haven't measured, you haven't optimised — you've just changed things.
Common Mistakes
Replacing every loadChildren call with loadComponent during a standalone migration.
This is the most common mistake I see. Standalone components and route architecture are separate concerns. A standalone component works perfectly inside a loadChildren route file. Migrating one does not require changing the other. I've reviewed PRs where an engineer replaced every loadChildren call in a single commit and labelled it a "standalone migration" — it wasn't. It was an architectural change that happened to compile cleanly.
Losing hierarchical route structure.
When loadChildren is replaced with flat loadComponent routes, child route hierarchy disappears. Guards, resolvers, and providers that once applied at the feature level must now be repeated per route. This surfaces in code review as canActivate: [AuthGuard] duplicated across every admin route — a clear sign that a feature boundary was missed.
Treating standalone components as an architecture strategy.
Standalone components improve dependency declaration and compilation. They say nothing about how routes should be organised. The routing structure decisions still belong to the engineering team.
Optimising without measuring.
Run bundle analysis before and after any routing restructure. Smaller bundles are not automatically better. More chunks are not automatically better. Your preloading strategy changes what "better" means.
When loadChildren Is Overkill
The case for loadChildren at feature boundaries holds for medium-to-large applications. It is not universally correct.
A small internal tool. A side project. A marketing site. A single-team application with eight routes. These gain little from introducing route files and feature boundaries everywhere. The abstraction costs more than it saves.
The honest rule: use loadChildren when the feature boundary is real — when there are multiple related routes, shared providers, and a clear reason to group them together. Don't introduce it to impose large-application structure on a codebase that isn't there yet. Premature route architecture is still premature optimisation.
The inflection point is usually recognisable: when you find yourself duplicating guards across related routes, or when a new developer can't tell which routes belong together by reading the root configuration, the feature boundary has been missed and loadChildren will pay for itself quickly.
What I Use in Production
On a 600+ component Angular platform serving enterprise clients, both strategies coexist and have distinct jobs.
Feature domains — client configuration, reporting, user administration, the main product dashboard — all use loadChildren. These are coherent domains with their own providers, guards, and sub-navigation. Fragmenting them into individual loadComponent calls would make the routing configuration harder to read and the feature boundaries harder to maintain. In a monorepo, these feature route files map directly to library boundaries, which means the routing structure reflects actual team ownership.
Isolated screens — the help centre, terms pages, error boundaries, and a handful of rarely visited informational pages — use loadComponent. No sub-routes, no shared dependencies, no reason to create a route file.
Nobody on the team debates the APIs in isolation. The conversation is usually about ownership, shared dependencies, and deployment boundaries. The routing decision follows from those answers.
Decision Matrix
| Scenario | Recommendation | Reason |
|---|---|---|
| Help / About / Terms pages | loadComponent | Isolated, no sub-routes, no shared dependencies |
| Error boundaries | loadComponent | Independent, no feature services |
| Admin area | loadChildren | Feature domain with sub-routes, shared guards, shared services |
| Reporting dashboard | loadChildren | Multiple related routes, shared data services |
| Multi-step checkout flow | loadChildren | Shared state, guards, sequential child routes |
| User account section | loadChildren | Profile, billing, security — related routes with shared context |
| Marketing pages | loadComponent | Independent, no feature services |
| Small internal tool (<8 routes total) | loadComponent | Overhead of feature files not justified |
| Feature-rich business domain | loadChildren | Architecture boundary, not just a routing convenience |
Final Thoughts
Most routing mistakes aren't caused by choosing the wrong API. They're caused by placing the lazy-loading boundary in the wrong place.
loadComponent works best when a route represents a genuinely independent screen — one component, no children, no shared dependencies.
loadChildren works best when a route represents a feature domain — a coherent set of routes that share providers, guards, and ownership.
The strongest Angular routing configurations use both. Not because mixing APIs is sophisticated, but because real applications contain both isolated screens and feature domains. The routing configuration should reflect that honestly.
When evaluating a route, I've stopped asking "which API should I use?" I ask: what is the actual boundary here?
If the answer is "a page," I reach for loadComponent.
If the answer is "a feature," I reach for loadChildren.
Once the boundary is clear, the API choice is obvious.
If you're in the middle of a standalone migration and replacing loadChildren calls wholesale — slow down. Ask whether each replacement is an architectural decision or a syntax preference. The answer is not always the same, and the difference matters six months from now.
References
- Website: sanketbhor.dev
SOCIAL SHARE CARD GENERATOR