@ContentChild and content projection in Angular - Performance & Optimization

Performance: @ContentChild and content projection

MEDIUM IMPACT

This concept affects rendering speed and interaction responsiveness by how Angular queries and projects DOM nodes inside components.

Accessing projected content efficiently inside a component

Angular

import { Component, ContentChild, AfterContentInit, ElementRef } from '@angular/core';

@Component({
  selector: 'good-projection',
  template: `<ng-content></ng-content>`
})
export class GoodProjectionComponent implements AfterContentInit {
  @ContentChild('projectedRef', { static: false }) projectedElement!: ElementRef;

  ngAfterContentInit() {
    const el = this.projectedElement.nativeElement;
    const height = el.offsetHeight;
    const width = el.offsetWidth;
    console.log(height, width);
  }
}

Caching nativeElement properties reduces layout thrashing by avoiding repeated reflows.

📈 Performance GainSingle reflow triggered instead of multiple, improving input responsiveness.

Accessing projected content efficiently inside a component

Angular

import { Component, ContentChild, AfterContentInit, ElementRef } from '@angular/core';

@Component({
  selector: 'bad-projection',
  template: `<ng-content></ng-content>`
})
export class BadProjectionComponent implements AfterContentInit {
  @ContentChild('projectedRef', { static: false }) projectedElement!: ElementRef;

  ngAfterContentInit() {
    // Accessing nativeElement multiple times
    console.log(this.projectedElement.nativeElement.offsetHeight);
    console.log(this.projectedElement.nativeElement.offsetWidth);
  }
}

Accessing nativeElement properties multiple times triggers multiple layout calculations causing reflows.

📉 Performance CostTriggers 2 reflows per component instance, slowing interaction responsiveness.

Performance Comparison

Pattern	DOM Operations	Reflows	Paint Cost	Verdict
Multiple nativeElement reads in ngAfterContentInit	Single query, multiple property reads	2 reflows	Medium paint cost	[X] Bad
Single nativeElement read cached in variable	Single query, single property read	1 reflow	Low paint cost	[OK] Good
@ContentChild query in ngAfterContentChecked	Multiple queries per cycle	Multiple reflows	High paint cost	[X] Bad
@ContentChild query in ngAfterContentInit only	Single query	1 reflow	Low paint cost	[OK] Good

Rendering Pipeline

Angular processes content projection by inserting projected nodes into the component's view. @ContentChild queries the projected DOM nodes after projection. Accessing nativeElement properties can trigger style recalculations and layout (reflow).

→Style Calculation

→Layout

→Paint

⚠️ BottleneckLayout stage is most expensive due to reflows triggered by DOM property reads.

Core Web Vital Affected

INP

This concept affects rendering speed and interaction responsiveness by how Angular queries and projects DOM nodes inside components.

Optimization Tips

1Query @ContentChild once in ngAfterContentInit, not repeatedly in ngAfterContentChecked.

2Cache nativeElement properties to avoid multiple layout reflows.

3Avoid heavy DOM access inside frequently called lifecycle hooks to keep interaction smooth.

Performance Quiz - 3 Questions

What is the main performance risk when accessing nativeElement properties multiple times in @ContentChild?

A Increases JavaScript bundle size

B Triggers multiple layout reflows slowing interaction

C Blocks network requests

D Causes memory leaks

DevTools: Performance

How to check: Open Chrome DevTools > Performance tab. Record while interacting with the component. Look for Layout events and their frequency.

What to look for: Frequent Layout events indicate repeated reflows caused by DOM property reads or queries. Fewer Layout events mean better performance.