Slow computations link

On every change detection cycle, Angular synchronously:

• Evaluates all template expressions in all components, unless specified otherwise, based on that each component's detection strategy
• Executes the ngDoCheck , ngAfterContentChecked , ngAfterViewChecked , and ngOnChanges lifecycle hooks. A single slow computation within a template or a lifecycle hook can slow down the entire change detection process because Angular runs the computations sequentially.

Identifying slow computations link

You can identify heavy computations with Angular DevTools’ profiler. In the performance timeline, click a bar to preview a particular change detection cycle. This displays a bar chart, which shows how long the framework spent in change detection for each component. When you click a component, you can preview how long Angular spent evaluating its template and lifecycle hooks.

For example, in the preceding screenshot, the second recorded change detection cycle is selected. Angular spent over 573 ms on this cycle, with the most time spent in the EmployeeListComponent . In the details panel, you can see that Angular spent over 297 ms evaluating the template of the EmployeeListComponent .

Optimizing slow computations link

Here are several techniques to remove slow computations:

• Optimizing the underlying algorithm . This is the recommended approach. If you can speed up the algorithm that is causing the problem, you can speed up the entire change detection mechanism.
• Caching using pure pipes . You can move the heavy computation to a pure pipe. Angular reevaluates a pure pipe only if it detects that its inputs have changed, compared to the previous time Angular called it.
• Using memoization . Memoization is a similar technique to pure pipes, with the difference that pure pipes preserve only the last result from the computation where memoization could store multiple results.
• Avoid repaints/reflows in lifecycle hooks . Certain operations cause the browser to either synchronously recalculate the layout of the page or re-render it. Since reflows and repaints are generally slow, you want to avoid performing them in every change detection cycle.

Pure pipes and memoization have different trade-offs. Pure pipes are an Angular built-in concept compared to memoization, which is a general software engineering practice for caching function results. The memory overhead of memoization could be significant if you invoke the heavy computation frequently with different arguments.

Resolving zone pollution link

Zone.js is a signaling mechanism that Angular uses to detect when an application state might have changed. It captures asynchronous operations like setTimeout , network requests, and event listeners. Angular schedules change detection based on signals from Zone.js

In some cases scheduled tasks or microtasks don’t make any changes in the data model, which makes running change detection unnecessary. Common examples are:

• requestAnimationFrame , setTimeout or setInterval
• Task or microtask scheduling by third-party libraries

This section covers how to identify such conditions, and how to run code outside the Angular zone to avoid unnecessary change detection calls.

Identifying unnecessary change detection calls link

You can detect unnecessary change detection calls using Angular DevTools. Often they appear as consecutive bars in the profiler’s timeline with source setTimeout , setInterval , requestAnimationFrame , or an event handler. When you have limited calls within your application of these APIs, the change detection invocation is usually caused by a third-party library.

In the image above, there is a series of change detection calls triggered by event handlers associated with an element. That’s a common challenge when using third-party, non-native Angular components, which do not alter the default behavior of NgZone .

Run tasks outside NgZone link

In such cases, you can instruct Angular to avoid calling change detection for tasks scheduled by a given piece of code using NgZone.

      
        content_copy
      
      import { Component, NgZone, OnInit } from '@angular/core';
@Component(...)
class AppComponent implements OnInit {
  constructor(private ngZone: NgZone) {}
  ngOnInit() {
    this.ngZone.runOutsideAngular(() => setInterval(pollForUpdates), 500);
  }
}
    

The preceding snippet instructs Angular to call setInterval outside the Angular Zone and skip running change detection after pollForUpdates runs.

Third-party libraries commonly trigger unnecessary change detection cycles because they weren't authored with Zone.js in mind. Avoid these extra cycles by calling library APIs outside the Angular zone:

      
        content_copy
      
      import { Component, NgZone, OnInit } from '@angular/core';
import * as Plotly from 'plotly.js-dist-min';

@Component(...)
class AppComponent implements OnInit {
  constructor(private ngZone: NgZone) {}
  ngOnInit() {
    this.ngZone.runOutsideAngular(() => {
      Plotly.newPlot('chart', data);
    });
  }
}
    

Running Plotly.newPlot('chart', data); within runOutsideAngular instructs the framework that it shouldn’t run change detection after the execution of tasks scheduled by the initialization logic.

For example, if Plotly.newPlot('chart', data) adds event listeners to a DOM element, Angular does not run change detection after the execution of their handlers.

Angular change detection and runtime optimization link

Change detection is the process through which Angular checks to see whether your application state has changed, and if any DOM needs to be updated. At a high level, Angular walks your components from top to bottom, looking for changes. Angular runs its change detection mechanism periodically so that changes to the data model are reflected in an application’s view. Change detection can be triggered either manually or through an asynchronous event (for example, a user interaction or an XMLHttpRequest completion).

Change detection is a highly optimized performant, but it can still cause slowdowns if the application runs it too frequently.

In this guide, you’ll learn how to control and optimize the change detection mechanism by skipping parts of your application and running change detection only when necessary.

Watch this video if you prefer to learn more about performance optimizations in a media format:

Class and style binding link

Use class and style bindings to add and remove CSS class names from an element's class attribute and to set styles dynamically.

Prerequisites link

• Property binding

Binding to a single CSS class link

To create a single class binding, type the following:

[class.sale]="onSale"

Angular adds the class when the bound expression, onSale is truthy, and it removes the class when the expression is falsy—with the exception of undefined . See styling delegation for more information.

Binding to multiple CSS classes link

To bind to multiple classes, type the following:

[class]="classExpression"

The expression can be one of:

• A space-delimited string of class names.
• An object with class names as the keys and truthy or falsy expressions as the values.
• An array of class names.

With the object format, Angular adds a class only if its associated value is truthy.

If there are multiple bindings to the same class name, Angular uses styling precedence to determine which binding to use.

The following table summarizes class binding syntax.

Binding to a single style link

To create a single style binding, use the prefix style followed by a dot and the name of the CSS style.

For example, to set the width style, type the following: [style.width]="width"

Angular sets the property to the value of the bound expression, which is usually a string. Optionally, you can add a unit extension like em or % , which requires a number type.

1. To write a style in dash-case, type the following:

         
           content_copy
         
         <nav [style.background-color]="expression"></nav>
       

2. To write a style in camelCase, type the following:

         
           content_copy
         
         <nav [style.backgroundColor]="expression"></nav>
       

Binding to multiple styles link

To toggle multiple styles, bind to the [style] attribute—for example, [style]="styleExpression" . The styleExpression can be one of:

• A string list of styles such as "width: 100px; height: 100px; background-color: cornflowerblue;" .
• An object with style names as the keys and style values as the values, such as {width: '100px', height: '100px', backgroundColor: 'cornflowerblue'} .

Note that binding an array to [style] is not supported.

Single and multiple-style binding example link

      
        content_copy
      
      @Component({
  selector: 'app-nav-bar',
  template: `
<nav [style]='navStyle'>
  <a [style.text-decoration]="activeLinkStyle">Home Page</a>
  <a [style.text-decoration]="linkStyle">Login</a>
</nav>`
})
export class NavBarComponent {
  navStyle = 'font-size: 1.2rem; color: cornflowerblue;';
  linkStyle = 'underline';
  activeLinkStyle = 'overline';
  /* . . . */
}
    

If there are multiple bindings to the same style attribute, Angular uses styling precedence to determine which binding to use.

The following table summarizes style binding syntax.

Styling precedence link

A single HTML element can have its CSS class list and style values bound to multiple sources (for example, host bindings from multiple directives).

What’s next link

• Component styles
• Introduction to Angular animations