Let’s explore them in\u00a0 more detail.<\/h2>\nMisusing the Default Change Detection Strategy<\/h3>\n![\"change](\"https:\/\/www.tothenew.com\/blog\/wp-ttn-blog\/uploads\/2026\/02\/change-detection-300x200.webp\")
change detection<\/p><\/div>\n
At first, I used the default change detection strategy everywhere in my work.<\/p>\n
For small apps, the default strategy works very well. But as the component tree gets bigger, it causes change detection to happen in big parts of the application, which slows it down and makes it check things that don’t need to be checked. Using OnPush only checks for changes when inputs change, which makes our app more efficient and predictable.<\/p>\n
Default Strategy<\/strong><\/p>\n@Component({\r\n selector: 'app-user-card',\r\n templateUrl: '.\/user-card.component.html'\r\n})\r\nexport class UserCardComponent {\r\n @Input() user!: User;\r\n}<\/pre>\nOptimized with OnPush<\/strong><\/p>\nimport { ChangeDetectionStrategy } from '@angular\/core';\r\n\r\n@Component({\r\n\u00a0 \u00a0 \u00a0selector: 'app-user-card',\r\n\u00a0 \u00a0 \u00a0templateUrl: '.\/user-card.component.html',\r\n\u00a0 \u00a0 \u00a0changeDetection: ChangeDetectionStrategy.OnPush\r\n})\r\nexport class UserCardComponent {\r\n\u00a0 \u00a0 \u00a0@Input() user!: User;\r\n}<\/pre>\nWhen to use it:
\nUse OnPush for components that only show things, components with inputs that can’t be changed, big lists, or parts of your app that need to be fast and where you want more control over change detection.<\/p>\n
Switching to OnPush on one of our enterprise dashboards with thousands of rows cut down on unnecessary re-renders and made the dashboard much more responsive.<\/p>\n
Poor Subscription Management in Reactive Angular Apps<\/h2>\n![\"Subscribe](\"https:\/\/www.tothenew.com\/blog\/wp-ttn-blog\/uploads\/2026\/02\/unsubscribe-300x171.webp\")
Subscribing Without Unsubscribing<\/p><\/div>\n
If you subscribe to Observables without unsubscribing, your Angular app may have memory leaks that you don’t know about. If a component is destroyed but the subscription is still active, it keeps listening and running logic that isn’t needed. This can slow down your app over time and make it act in ways you didn’t expect.<\/p>\n
Bad Example:<\/p>\n
ngOnInit() {\r\n this.userService.getUsers().subscribe(users => {\r\n this.users = users;\r\n });\r\n}<\/pre>\nIf the component is destroyed, the subscription may still remain active.<\/p>\n
A better approach:
\nUse takeUntil, AsyncPipe, or manually unsubscribe in ngOnDestroy.<\/p>\n
private destroy$ = new Subject<void>();\r\n\r\nngOnInit() {\r\nthis.userService.getUsers()\r\n.pipe(takeUntil(this.destroy$))\r\n.subscribe(users => {\r\n\u00a0 \u00a0 this.users = users;\r\n});\r\n}\r\n\r\nngOnDestroy() {\r\n\u00a0 \u00a0 this.destroy$.next();\r\n\u00a0 \u00a0 this.destroy$.complete();\r\n}\r\n\r\n<\/pre>\nUsing AsyncPipe example<\/p>\n
HTML<\/strong>\r\n<div *ngFor=\"let user of users$ | async\">\r\n {{ user.name }}\r\n<\/div>\r\n\r\nTypescript<\/strong>\r\n \r\nusers$ = this.userService.getUsers();<\/pre>\nManaging subscriptions properly keeps your app clean, efficient, and memory-safe.<\/p>\n
Not Using trackBy in ngFor<\/h2>\n![\"TrackBy\"](\"https:\/\/www.tothenew.com\/blog\/wp-ttn-blog\/uploads\/2026\/02\/track-by-300x169.webp\")
TrackBy<\/p><\/div>\n
Angular tracks list items by object reference when you don’t use trackBy in *ngFor. Angular might re-render the whole list instead of just what changed if the array changes even a little bit. This can cause a lot of DOM re-renders and slow down performance in applications that use a lot of data.<\/p>\n
Bad approach:<\/p>\n
If the users array is replaced (even with the same data), Angular recreates all DOM elements.<\/p>\n
<li *ngFor=\"let user of users\">\r\n {{ user.name }}\r\n<\/li><\/pre>\nGood approach:<\/p>\n
\/\/ HTML\r\n<li *ngFor=\"let item of items; trackBy: trackById\">\r\n {{ item.name }}\r\n<\/li>\r\n\r\n\/\/ Typescript\r\ntrackById(index: number, item: any) {\r\n return item.id;\r\n}<\/pre>\nUsing trackBy helps Angular figure out which items really changed, which stops unnecessary DOM re-renders and speeds things up, especially in big lists or lists that change often.<\/p>\n
This is especially critical for:<\/p>\n
\n- Tables<\/li>\n
- Virtual scroll<\/li>\n
- Data-heavy dashboards<\/li>\n<\/ul>\n
When you didn’t use trackBy in big data tables, the whole table would re-render every time you refreshed with a small data or even if only one row changed.<\/p>\n
Not Using Lazy Loading and Angular’s Feature Modules<\/h2>\n
Combining everything into a single Angular module may work initially, but as the application expands and grow. It becomes disorganised, challenging to scale, and difficult to maintain. Large modules make lazy loading impossible, increase coupling, and slow down compilation.<\/p>\n
Bad approach: All features live in one place with no clear separation.<\/p>\n
@NgModule({\r\n declarations: [\r\n AppComponent,\r\n HeaderComponent,\r\n DashboardComponent,\r\n UserListComponent,\r\n AdminComponent,\r\n ReportsComponent\r\n ],\r\nimports: [\r\n BrowserModule,\r\n FormsModule,\r\n ReactiveFormsModule,\r\n HttpClientModule\r\n ]\r\n})\r\nexport class AppModule {}<\/pre>\nBetter approach: Feature modules. Now your app is modular, organized, and ready for lazy loading.<\/p>\n
@NgModule({\r\n declarations: [UserListComponent],\r\n imports: [CommonModule],\r\n})\r\nexport class UsersModule {}\r\n\r\n@NgModule({\r\n declarations: [AdminComponent],\r\n imports: [CommonModule],\r\n})\r\nexport class AdminModule {}<\/pre>\nWhen to split modules:<\/p>\n
\n- When a feature has multiple related components<\/li>\n
- When you want lazy loading<\/li>\n
- When different teams work on separate features<\/li>\n
- When the module starts becoming too large<\/li>\n<\/ul>\n
Small, focused modules make your Angular app cleaner, scalable, and easier to maintain.<\/p>\n
Not Using Angular HTTP Interceptors for Centralized Error Handling<\/h2>\n![\"Error](\"https:\/\/www.tothenew.com\/blog\/wp-ttn-blog\/uploads\/2026\/02\/error2-300x300.png\")
Error handling<\/p><\/div>\n
When Angular HTTP Interceptors are not used for centralised error handling, each component or service handles errors independently, resulting in repetitive code and inconsistent user experience. Uncaught errors can cause your app to crash or confuse users.<\/p>\n
Create\u00a0 an HTTP interceptor<\/p>\n
@Injectable()\r\nexport class ErrorInterceptor implements HttpInterceptor {\r\n intercept(req: HttpRequest<any>, next: HttpHandler) {\r\n return next.handle(req).pipe(\r\n catchError((error: HttpErrorResponse) => {\r\n console.error('Global Error:', error.message);\r\n return throwError(() => error);\r\n })\r\n );\r\n }\r\n}<\/pre>\nUsing a global handler:<\/p>\n
@Injectable()\r\nexport class GlobalErrorHandler implements ErrorHandler {\r\n handleError(error: any) {\r\n console.error('Global error:', error);\r\n \/\/ show notification or log to server\r\n }\r\n}\r\n\/\/ Add it to the AppModule\r\n@NgModule({\r\n providers: [{ provide: ErrorHandler, useClass: GlobalErrorHandler }]\r\n})\r\nexport class AppModule {}<\/pre>\nWhy it helps:<\/strong><\/p>\n\n- Centralized error management<\/li>\n
- Consistent user notifications<\/li>\n
- Cleaner, maintainable code<\/li>\n
- Easier logging and monitoring<\/li>\n<\/ul>\n
Global error handling makes your app more robust, predictable and professional.<\/p>\n
Ignoring Angular-Specific Performance Tools<\/h2>\n![\"Performance](\"https:\/\/www.tothenew.com\/blog\/wp-ttn-blog\/uploads\/2026\/02\/speed-247x300.png\")
Performance Boost<\/p><\/div>\n
Small Angular apps may become sluggish and unresponsive as they grow if performance is not considered early on. Longer load times and a slow user interface result from ignoring optimisations like OnPush, lazy loading, or effective change detection.<\/p>\n
In large Angular applications, I always evaluate:<\/p>\n
\u2022 Lazy loading at the route level with Angular Router
\n\u2022 Tailored preloading techniques
\n\u2022 Using Angular CLI build statistics to determine bundle size
\n\u2022 Choosing a change detection strategy
\n\u2022 RxJS operators such as debounceIt’s time for events driven by users<\/p>\n
Example:<\/p>\n
searchControl.valueChanges\r\n.pipe(debounceTime(400))\r\n.subscribe(value => {\r\n this.search(value);\r\n});<\/pre>\nConclusion<\/h2>\n
Even though Angular is a powerful tool, writing code alone is not enough to create scalable and maintainable applications. Performance and long-term maintainability can be greatly enhanced by implementing techniques like OnPush change detection, trackBy in ngFor, structured feature modules, appropriate subscription management, and centralised error handling.<\/p>\n
The framework does not cause large Angular applications to fail. Architectural choices are the reason they fail.<\/p>\n
You can create systems that are quick, dependable, and maintainable even as they grow if you comprehend how Angular’s change detection, dependency injection, routing, and reactive patterns operate internally.<\/p>\n","protected":false},"excerpt":{"rendered":"
Introduction There is no doubt that Angular is powerful. But after using Angular\u00a0 from v1 to v20 in real production systems, I found that most performance problems and messy codebases come from a small number of mistakes that keep happening. In this article, I’ll talk about what I’ve learned from my own projects that helped […]<\/p>\n","protected":false},"author":1764,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":0},"categories":[5876],"tags":[955,4117],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/77908"}],"collection":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/users\/1764"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/comments?post=77908"}],"version-history":[{"count":7,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/77908\/revisions"}],"predecessor-version":[{"id":78082,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/77908\/revisions\/78082"}],"wp:attachment":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/media?parent=77908"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/categories?post=77908"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/tags?post=77908"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
change detection<\/p><\/div>\n
At first, I used the default change detection strategy everywhere in my work.<\/p>\n
For small apps, the default strategy works very well. But as the component tree gets bigger, it causes change detection to happen in big parts of the application, which slows it down and makes it check things that don’t need to be checked. Using OnPush only checks for changes when inputs change, which makes our app more efficient and predictable.<\/p>\n
Default Strategy<\/strong><\/p>\n Optimized with OnPush<\/strong><\/p>\n When to use it: Switching to OnPush on one of our enterprise dashboards with thousands of rows cut down on unnecessary re-renders and made the dashboard much more responsive.<\/p>\n Subscribing Without Unsubscribing<\/p><\/div>\n If you subscribe to Observables without unsubscribing, your Angular app may have memory leaks that you don’t know about. If a component is destroyed but the subscription is still active, it keeps listening and running logic that isn’t needed. This can slow down your app over time and make it act in ways you didn’t expect.<\/p>\n Bad Example:<\/p>\n If the component is destroyed, the subscription may still remain active.<\/p>\n A better approach: Using AsyncPipe example<\/p>\n Managing subscriptions properly keeps your app clean, efficient, and memory-safe.<\/p>\n TrackBy<\/p><\/div>\n Angular tracks list items by object reference when you don’t use trackBy in *ngFor. Angular might re-render the whole list instead of just what changed if the array changes even a little bit. This can cause a lot of DOM re-renders and slow down performance in applications that use a lot of data.<\/p>\n Bad approach:<\/p>\n If the users array is replaced (even with the same data), Angular recreates all DOM elements.<\/p>\n Good approach:<\/p>\n Using trackBy helps Angular figure out which items really changed, which stops unnecessary DOM re-renders and speeds things up, especially in big lists or lists that change often.<\/p>\n This is especially critical for:<\/p>\n When you didn’t use trackBy in big data tables, the whole table would re-render every time you refreshed with a small data or even if only one row changed.<\/p>\n Combining everything into a single Angular module may work initially, but as the application expands and grow. It becomes disorganised, challenging to scale, and difficult to maintain. Large modules make lazy loading impossible, increase coupling, and slow down compilation.<\/p>\n Bad approach: All features live in one place with no clear separation.<\/p>\n Better approach: Feature modules. Now your app is modular, organized, and ready for lazy loading.<\/p>\n When to split modules:<\/p>\n Small, focused modules make your Angular app cleaner, scalable, and easier to maintain.<\/p>\n Error handling<\/p><\/div>\n When Angular HTTP Interceptors are not used for centralised error handling, each component or service handles errors independently, resulting in repetitive code and inconsistent user experience. Uncaught errors can cause your app to crash or confuse users.<\/p>\n Create\u00a0 an HTTP interceptor<\/p>\n Using a global handler:<\/p>\n Why it helps:<\/strong><\/p>\n Global error handling makes your app more robust, predictable and professional.<\/p>\n Performance Boost<\/p><\/div>\n Small Angular apps may become sluggish and unresponsive as they grow if performance is not considered early on. Longer load times and a slow user interface result from ignoring optimisations like OnPush, lazy loading, or effective change detection.<\/p>\n In large Angular applications, I always evaluate:<\/p>\n \u2022 Lazy loading at the route level with Angular Router Example:<\/p>\n Even though Angular is a powerful tool, writing code alone is not enough to create scalable and maintainable applications. Performance and long-term maintainability can be greatly enhanced by implementing techniques like OnPush change detection, trackBy in ngFor, structured feature modules, appropriate subscription management, and centralised error handling.<\/p>\n The framework does not cause large Angular applications to fail. Architectural choices are the reason they fail.<\/p>\n You can create systems that are quick, dependable, and maintainable even as they grow if you comprehend how Angular’s change detection, dependency injection, routing, and reactive patterns operate internally.<\/p>\n","protected":false},"excerpt":{"rendered":" Introduction There is no doubt that Angular is powerful. But after using Angular\u00a0 from v1 to v20 in real production systems, I found that most performance problems and messy codebases come from a small number of mistakes that keep happening. In this article, I’ll talk about what I’ve learned from my own projects that helped […]<\/p>\n","protected":false},"author":1764,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":0},"categories":[5876],"tags":[955,4117],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/77908"}],"collection":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/users\/1764"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/comments?post=77908"}],"version-history":[{"count":7,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/77908\/revisions"}],"predecessor-version":[{"id":78082,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/77908\/revisions\/78082"}],"wp:attachment":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/media?parent=77908"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/categories?post=77908"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/tags?post=77908"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}@Component({\r\n selector: 'app-user-card',\r\n templateUrl: '.\/user-card.component.html'\r\n})\r\nexport class UserCardComponent {\r\n @Input() user!: User;\r\n}<\/pre>\nimport { ChangeDetectionStrategy } from '@angular\/core';\r\n\r\n@Component({\r\n\u00a0 \u00a0 \u00a0selector: 'app-user-card',\r\n\u00a0 \u00a0 \u00a0templateUrl: '.\/user-card.component.html',\r\n\u00a0 \u00a0 \u00a0changeDetection: ChangeDetectionStrategy.OnPush\r\n})\r\nexport class UserCardComponent {\r\n\u00a0 \u00a0 \u00a0@Input() user!: User;\r\n}<\/pre>\n
\nUse OnPush for components that only show things, components with inputs that can’t be changed, big lists, or parts of your app that need to be fast and where you want more control over change detection.<\/p>\nPoor Subscription Management in Reactive Angular Apps<\/h2>\n
ngOnInit() {\r\n this.userService.getUsers().subscribe(users => {\r\n this.users = users;\r\n });\r\n}<\/pre>\n
\nUse takeUntil, AsyncPipe, or manually unsubscribe in ngOnDestroy.<\/p>\nprivate destroy$ = new Subject<void>();\r\n\r\nngOnInit() {\r\nthis.userService.getUsers()\r\n.pipe(takeUntil(this.destroy$))\r\n.subscribe(users => {\r\n\u00a0 \u00a0 this.users = users;\r\n});\r\n}\r\n\r\nngOnDestroy() {\r\n\u00a0 \u00a0 this.destroy$.next();\r\n\u00a0 \u00a0 this.destroy$.complete();\r\n}\r\n\r\n<\/pre>\nHTML<\/strong>\r\n<div *ngFor=\"let user of users$ | async\">\r\n {{ user.name }}\r\n<\/div>\r\n\r\nTypescript<\/strong>\r\n \r\nusers$ = this.userService.getUsers();<\/pre>\nNot Using trackBy in ngFor<\/h2>\n
<li *ngFor=\"let user of users\">\r\n {{ user.name }}\r\n<\/li><\/pre>\n\/\/ HTML\r\n<li *ngFor=\"let item of items; trackBy: trackById\">\r\n {{ item.name }}\r\n<\/li>\r\n\r\n\/\/ Typescript\r\ntrackById(index: number, item: any) {\r\n return item.id;\r\n}<\/pre>\n\n
Not Using Lazy Loading and Angular’s Feature Modules<\/h2>\n
@NgModule({\r\n declarations: [\r\n AppComponent,\r\n HeaderComponent,\r\n DashboardComponent,\r\n UserListComponent,\r\n AdminComponent,\r\n ReportsComponent\r\n ],\r\nimports: [\r\n BrowserModule,\r\n FormsModule,\r\n ReactiveFormsModule,\r\n HttpClientModule\r\n ]\r\n})\r\nexport class AppModule {}<\/pre>\n@NgModule({\r\n declarations: [UserListComponent],\r\n imports: [CommonModule],\r\n})\r\nexport class UsersModule {}\r\n\r\n@NgModule({\r\n declarations: [AdminComponent],\r\n imports: [CommonModule],\r\n})\r\nexport class AdminModule {}<\/pre>\n\n
Not Using Angular HTTP Interceptors for Centralized Error Handling<\/h2>\n
@Injectable()\r\nexport class ErrorInterceptor implements HttpInterceptor {\r\n intercept(req: HttpRequest<any>, next: HttpHandler) {\r\n return next.handle(req).pipe(\r\n catchError((error: HttpErrorResponse) => {\r\n console.error('Global Error:', error.message);\r\n return throwError(() => error);\r\n })\r\n );\r\n }\r\n}<\/pre>\n@Injectable()\r\nexport class GlobalErrorHandler implements ErrorHandler {\r\n handleError(error: any) {\r\n console.error('Global error:', error);\r\n \/\/ show notification or log to server\r\n }\r\n}\r\n\/\/ Add it to the AppModule\r\n@NgModule({\r\n providers: [{ provide: ErrorHandler, useClass: GlobalErrorHandler }]\r\n})\r\nexport class AppModule {}<\/pre>\n\n
Ignoring Angular-Specific Performance Tools<\/h2>\n
\n\u2022 Tailored preloading techniques
\n\u2022 Using Angular CLI build statistics to determine bundle size
\n\u2022 Choosing a change detection strategy
\n\u2022 RxJS operators such as debounceIt’s time for events driven by users<\/p>\nsearchControl.valueChanges\r\n.pipe(debounceTime(400))\r\n.subscribe(value => {\r\n this.search(value);\r\n});<\/pre>\nConclusion<\/h2>\n