Angular rendering and SSR performance

Improves measured rendering and loading costs while keeping server rendering and browser hydration compatible.

angular-performance-ssr

See how it helps

When is it useful?

Use when Angular lists, charts or initial page loads feel slow, especially in an SSR application.

What does it help you do?

Reduces repeated template computation and preserves item identity when lists change.
Uses existing lazy loading, deferred rendering or pagination where supported.
Protects browser-only APIs and avoids DOM changes that break hydration.

Try asking this

Profile our long order list, reduce unnecessary rendering and verify direct server-rendered loads still hydrate correctly. Use the same large dataset before and after the change. Record rendering time and check that sorting does not recreate every visible row.

Detailed documentation

Read the skill’s original instructions, examples and checks in their authored language.

Details…Show less

Angular Performance & SSR

Measure before optimizing, eliminate unnecessary change-detection work and DOM thrashing, and keep code safe across browser and SSR/hydration environments when SSR is used.

1. Change detection and template rendering efficiency

Use ChangeDetectionStrategy.OnPush and reactive inputs (immutable object references, Signals, or async pipe) so Angular only re-checks subtrees whose inputs or local state actually changed.
Always provide a stable, unique identity in @for (item of items; track item.id) (or *ngFor="...; trackBy: trackById"). Never track by $index on lists that can be reordered, filtered, inserted into or deleted from.
Move formatting and derived calculations out of template method calls into computed() signals or pure @Pipe({ pure: true }) pipes.

2. Bundle size, lazy loading and `@defer`

Keep initial bundles lean with route-level loadComponent / loadChildren and, in Angular 17+, @defer (on viewport) / @defer (on interaction) with @placeholder, @loading and @error blocks for heavy below-the-fold widgets or charts.
For large lists (hundreds or thousands of rows), use pagination or @angular/cdk/scrolling (cdk-virtual-scroll-viewport) rather than rendering every DOM node at once.
Run tasks that fire at high frequency outside Angular's template needs (requestAnimationFrame, scroll/mousemove listeners) via NgZone.runOutsideAngular or passive listeners, re-entering only when UI state actually changes.

3. SSR and hydration safety (when `@angular/ssr` is present)

Guard browser-only globals (window, document, localStorage, ResizeObserver, IntersectionObserver) behind afterNextRender / afterRender (Angular 16+) or isPlatformBrowser( inject(PLATFORM_ID) ).
Avoid direct DOM manipulation that mutates server-rendered HTML structure before Angular hydration completes, and ensure withEventReplay() / HttpClient transfer cache is respected.

Before you finish

Lists use stable track item.id / trackBy, never $index on mutable lists.
OnPush and computed() / pure pipes avoid redundant work on every change-detection cycle.
Browser-only APIs are guarded when SSR/hydration is active.

Included files 2

LICENSE.txt
SKILL.md