Skill

Optimize Angular App Performance

Prioritized Angular performance rules covering change detection, bundle size, rendering, SSR, and state management.

Works with angular

79
Spark score
out of 100
Updated 24 days ago
Version 13.12.0

Add to Favorites

Why it matters

Enhance your Angular application's performance and user experience by implementing best practices for change detection, asynchronous operations, bundle optimization, and rendering.

Outcomes

What it gets done

01

Implement OnPush change detection and Signals for efficient updates.

02

Optimize bundle size with lazy loading and @defer.

03

Improve rendering performance using trackBy and virtual scrolling.

04

Configure SSR and hydration for faster initial loads.

Install

Add it to your toolbox

Run in your project directory:

curl -fsSL https://spark.entire.vc/get/ag-angular-best-practices | bash

Overview

Angular Best Practices

A prioritized Angular performance guide covering change detection (OnPush, signals, zoneless), async waterfalls, bundle optimization (lazy loading, @defer), rendering performance, SSR hydration, template optimization, state management, and memory management, with correct/incorrect code examples per rule. Use when writing, reviewing, or refactoring Angular code for performance, bundle size, or SSR; not needed for non-Angular frontend work.

What it does

Comprehensive performance optimization guide for Angular applications, with prioritized rules across eight categories: Change Detection (CRITICAL - signals, OnPush, zoneless), Async Waterfalls (CRITICAL - RxJS patterns, SSR preloading), Bundle Optimization (CRITICAL - lazy loading, tree shaking), Rendering Performance (HIGH - @defer, trackBy, virtualization), Server-Side Rendering (HIGH - hydration, prerendering), Template Optimization (MEDIUM - control flow, pipes), State Management (MEDIUM - signal patterns, selectors), and Memory Management (LOW-MEDIUM - cleanup, subscriptions).

When to use - and when NOT to

Use this when writing new Angular components or pages, implementing data fetching, reviewing code for performance issues, refactoring existing Angular code, optimizing bundle size or load times, or configuring SSR/hydration.

Not needed for non-Angular frontend work, or for a codebase where none of these performance concerns - bundle size, rendering, SSR - currently matter.

Inputs and outputs

Provides correct/incorrect code pairs per rule. Change Detection: ChangeDetectionStrategy.OnPush with signal() state instead of default change detection with mutable properties, and enabling zoneless Angular (v20+) via provideZonelessChangeDetection() for roughly 15KB smaller bundles and no zone.js patching. Async Operations: replacing nested subscriptions, or "waterfalls", with forkJoin for parallel fetches or switchMap for dependent calls, and using route resolvers instead of ngOnInit fetches to avoid client-side waterfalls in SSR. Bundle Optimization: lazy-loaded feature routes via loadChildren, @defer for heavy components, avoiding barrel-file re-exports, and dynamically importing third-party libraries.

// CORRECT - OnPush with Signals
@Component({
  changeDetection: ChangeDetectionStrategy.OnPush,
  template: `<div>{{ count() }}</div>`,
})
export class CounterComponent {
  count = signal(0);
}

Integrations

Rendering Performance: always using trackBy with @for, virtual scrolling for large lists, pure pipes over methods in templates, and computed() for derived data. Server-Side Rendering: incremental hydration configuration, deferring non-critical content, and TransferState to avoid re-fetching data already loaded server-side. Template Optimization: the new control-flow syntax (@if/@for) over structural directives, and avoiding complex template expressions. State Management: selectors to prevent unnecessary re-renders and colocating state with the features that own it. Memory Management: takeUntilDestroyed for RxJS subscription cleanup, and preferring signals over subscriptions where possible. A quick-reference checklist covers new-component, performance-review, and SSR-check criteria to run through before shipping, so each rule category has a concrete verification step rather than being applied only from memory.

Who it's for

Angular developers writing, reviewing, or refactoring components for performance, bundle size, and rendering efficiency who need concrete before/after code patterns, ranked by impact from critical to low-medium, rather than general Angular documentation explaining features in isolation.

FAQ

Common questions

Discussion

Questions & comments ยท 0

Sign In Sign in to leave a comment.