debuggingperformancedevtools

Memory leaks and slowdowns in TypeScript apps: diagnosis and fixes

UUnknown

2026-02-13

11 min read

Systematic workflow to find and fix memory leaks and CPU spikes in TypeScript apps—practical profiling, fixes, and 2026 tooling tips.

Why your TypeScript app gets slower over time — and how to stop it

Memory leaks and CPU spikes are the two stealthiest causes of slow TypeScript apps in both Node.js backends and browser frontends. They start small, then silently consume RAM or CPU until a host crashes, GC chokes, or users notice timeouts. This guide gives a systematic, practical workflow (and concrete TypeScript examples) to diagnose, fix, and prevent leaks and hotspots in 2026, with the latest tooling and patterns teams are using in late 2025 and early 2026.

Quick roadmap (read this first)

Reproduce and measure: collect stable metrics and a baseline.
Narrow the scope: browser vs Node, module, request, component.
Profile memory and CPU: heap snapshots + CPU/flame charts.
Analyze retainers and dominator trees; find the root.
Fix with targeted code changes and add automated regression tests.
Deploy with continuous monitoring and defensive patterns.

Why this matters in 2026

Two things changed in 2024–2026 that make leak hunting more urgent and more tractable:

Applications are heavier (Edge SSR, universal rendering, WebAssembly and hybrid edge workflows), so a single leak affects more resources.
Browser and Node tooling matured: the Node inspector + Chrome DevTools and newer profiling integrations (improved heap timelines, sampling profilers) make root-cause analysis faster when you know what to capture.

Step 1 — Reproduce reliably and gather baseline metrics

Without a reproducible signal you’ll hunt ghosts. Before diving into heap snapshots or flamegraphs, set up simple telemetry:

Collect memory RSS and heapUsed in Node (process.memoryUsage()).
Collect client-side memory and long tasks using Performance.measure and navigator.memory (when available).
Record CPU: sampling profiler traces from DevTools or Node inspector.

Example Node probe (TypeScript):

import fs from 'fs';
import { setInterval } from 'timers';

setInterval(() => {
  const mem = process.memoryUsage();
  fs.appendFileSync('mem.csv', `${Date.now()},${mem.heapUsed},${mem.rss}\n`);
}, 5000);

Practical tip

Run a steady workload (load test or recorded user session). Make sure traffic pattern is realistic; many leaks only appear under steady/long-lived load.

Step 2 — Narrow the scope

Identify whether the leak is in the browser or server:

Does memory climb across multiple users? Server-side leak likely.
Does one tab grow over time? Browser leak.

Isolate by disabling features or routing to a staging service. For single-page apps, reload & interact to reproduce. For Node, replicate with an isolated script that mimics request flow.

Step 3 — Capture the right profiles

Two complementary artefacts find different problems:

Heap snapshots (memory shape, retained sizes, dominator tree).
CPU profiles / flamegraphs (hot functions, long tasks, GC pressure).

Browser workflow (Chrome / Edge DevTools)

Open DevTools > Memory. Take an initial Heap snapshot.
Use "Allocation instrumentation on timeline" while exercising the app to capture allocations over time.
Take a second snapshot and run a diff. Inspect the Dominators and Retainers to find who holds objects alive.
For CPU: Performance > record for a user path and inspect the Flame Chart for long frames or heavy JS stacks.

Node workflow

Start Node with the inspector: node --inspect app.js and connect Chrome DevTools at chrome://inspect.
Use DevTools Memory panel to take heap snapshots from Node just like in browser. You can also use V8 heap profiling via node --heap-prof and process with --prof-process.
For CPU hotspots, collect a sampling profile in DevTools or use tools and low-cost setups to capture traces if you need inexpensive test hardware.

Production-safe captures

In production you often must use sampling or lightweight metrics: pprof-compatible exporters, periodic heap-dumps triggered by an endpoint (and downloaded for offline analysis), or eBPF/perf for system-level CPU hotspots. Avoid continuous heavy profiling in production unless you can direct profiles to a remote store for offline analysis. For architectures using edge and Kubernetes, follow best practices from hybrid edge workflows when attaching debuggers to running pods.

Step 4 — Analyze the heap: dominator trees, retainers, and leaks

Heap snapshots are the single most actionable artifact for memory leaks. Focus on:

Detached DOM nodes (browser): nodes that are no longer in document but still referenced.
Growing arrays/Maps/Sets and their keys.
Closures that hold large outer-scope objects.
Event listeners bound but not removed.

How to read the dominator tree

Sort by retained size. The dominator is the smallest set of objects that keep a subtree alive. A single suspicious dominator (e.g., an Array with huge retainedSize) points you to the module or closure that must release it.

Practical TypeScript anti-patterns that cause leaks

Below are common leaky patterns and immediate fixes. Each includes a short TypeScript example.

1. Unbounded caches

// leakyCache.ts — BAD
const cache = new Map();

export function cacheValue(key: string, value: any) {
  cache.set(key, value); // never evicted
}

Fix: use an LRU, limit size, or use WeakMap when keys are objects.

// fixedCache.ts — GOOD
import QuickLRU from 'quick-lru';

const cache = new QuickLRU({ maxSize: 1000 });
export function cacheValue(key: string, value: any) {
  cache.set(key, value);
}

2. Timers and intervals never cleared

// server.ts — BAD
setInterval(() => {
  // poll something and store result globally
}, 1000);

Fix: retain the timer id and clear on lifecycle events; on per-request timers ensure clearTimeout on finish.

// fixed.ts — GOOD
let timer: NodeJS.Timer | undefined;
function start() {
  timer = setInterval(poll, 1000);
}
function stop() {
  if (timer) clearInterval(timer);
}

3. Forgotten event listeners

// React component — BAD
useEffect(() => {
  window.addEventListener('resize', handleResize);
}, []); // no cleanup

Fix: remove listeners in cleanup.

// React component — GOOD
useEffect(() => {
  window.addEventListener('resize', handleResize);
  return () => window.removeEventListener('resize', handleResize);
}, []);

4. RxJS / event stream subscriptions never torn down

// rx-leak.ts — BAD
constructor() {
  this.obs$.subscribe(value => doWork(value)); // never unsubscribed
}

Fix: use takeUntil or store subscription and unsubscribe on destroy.

// rx-fixed.ts — GOOD
private onDestroy$ = new Subject();
ngOnInit() {
  this.obs$.pipe(takeUntil(this.onDestroy$)).subscribe(doWork);
}
ngOnDestroy() {
  this.onDestroy$.next();
  this.onDestroy$.complete();
}

5. Closures capturing large objects

When you capture a big object in a closure used long-term, that object stays alive. Refactor to avoid long-lived closures or null out references when done.

Step 5 — Fixes that actually work (with examples)

After you find the retaining path, apply one of these targeted strategies:

Release references: set large variables to null when done.
Switch Map > WeakMap: use WeakMap for object-key caches where appropriate.
Limit caches: implement LRU or TTL eviction.
Remove listeners: always pair add/remove for lifecycle events.
Refactor closure scope: move large data out of long-lived closures.

Using WeakMap safely

// goodWeakMap.ts
const metadata = new WeakMap();
function setMeta(obj: object, meta: Metadata) {
  metadata.set(obj, meta); // metadata dies with obj
}

Note: WeakMap keys must be objects. WeakMap does not expose size or iteration — it's a deliberate trade-off that prevents retention.

Troubleshooting CPU spikes

CPU issues often look like memory problems: heavy GC cycles, main-thread jank, or background event-loop saturation. The approach mirrors memory diagnosis:

Collect sampling CPU profiles across the timeframe where spikes occur.
Use flamegraphs to see hot stacks and top consumers.
Check for blocking synchronous work, large JSON.parse, serialization, or repeated expensive computations.

Practical examples:

Repeated synchronous crypto or hash computation in request handler — move to worker threads or async streams.
Heavy synchronous JSON.stringify on large objects — stream or serialize partially.
Excessive event-loop churn due to tight loops or frequent timers — batch or debounce.

Example: offload heavy work to a worker thread in Node

// workerTask.ts
import { parentPort } from 'worker_threads';
parentPort?.on('message', (data) => {
  const result = heavyComputation(data);
  parentPort?.postMessage(result);
});

// main.ts
import { Worker } from 'worker_threads';
function runTask(input: any) {
  return new Promise((resolve, reject) => {
    const w = new Worker('./workerTask.js');
    w.on('message', resolve);
    w.on('error', reject);
    w.postMessage(input);
  });
}

Tools that are essential in 2026

Chrome DevTools — heap snapshots, allocation timelines, performance traces (see Edge-first patterns for modern DevTools integrations).
Node Inspector (node --inspect) — connect DevTools to Node.
clinic.js — quick flamegraphs and performance doctoring for Node; you can run these tools on inexpensive test hardware or cloud instances when labs need to scale (budget hardware tips).
0x or 0x + flamegraph tools — deterministic flame graphs for Node.
Heap dump tools (heapdump, v8 heap profiler) for offline analysis; consider automating artifact collection in your pipelines with scripting or metadata tools (automated extraction workflows).
pprof/eBPF/perf for system-level CPU investigations in production environments; for guidance on when to escalate to native-level analysis see resources on cloud-cost and native toolchains (a CTO’s guide to storage costs & native considerations).

In late 2025 and into 2026, DevTools improved allocation instrumentation and made allocation stack capture more reliable across Node and Chromium-based browsers — use those capabilities to get stack traces for allocations instead of guessing.

Regression testing and prevention

Fixing a leak is only half the job — prevent regressions:

Add tests that assert memory usage after a workload (tolerance-based), using headless browsers or Node scripts.
Integrate periodic leak checks into CI with lightweight profiling builds — e.g., run a 60s scenario and compare heapUsed deltas. If you need small automation patterns or micro-tooling examples, look at micro-app case studies for ideas about tiny, testable flows.
Use code reviews to watch for anti-patterns: global caches, long-lived closures, missing teardown logic.

Example: a simple CI memory regression check

// ci-memory-check.ts — run under CI with a deterministic scenario
import { spawnSync } from 'child_process';

const result1 = spawnSync('node', ['runScenario.js']);
const result2 = spawnSync('node', ['runScenario.js']);
// Compare heapUsed reported by script; fail when difference > threshold

Monitoring in production

Set alerts on these signals:

Growing heapUsed or RSS over multiple collection windows.
High CPU load averages and long event-loop delay warnings (use Node's event-loop delay diagnostics).
Frequent GC Full pauses or long GC pause times.

Combine observability (APM traces, sampled profiles) with periodic heap dumps or pprof snapshots. If you use Kubernetes, use ephemeral debug pods to attach profilers to a live process and capture artifacts for offline analysis — patterns covered under hybrid edge workflows are useful for orchestrating that safely.

Antipatterns to avoid — a checklist

Global mutable caches without eviction.
Using Map for object-key caches instead of WeakMap when keys are objects.
Event listeners or intervals added without cleanup in component lifecycles.
Holding on to Request/Response objects beyond their lifecycle in Node.
Large in-memory queues instead of backpressure (streams, RxJS operators with proper buffering).

Short case study — real-world example (anonymized)

Team X saw Node processes slowly climb RSS until OOM in their analytics service. Steps they followed:

Recorded heapUsed over time and confirmed steady growth under load.
Connected Chrome DevTools to Node and took two heap snapshots 5 minutes apart.
Diff showed a growing Map instance holding thousands of objects; dominator tree pointed to a per-request cache added in middleware.
They replaced the Map with a QuickLRU instance with TTL and added unit-tests that simulate 100k requests to assert steady memory.
Deployed and monitored; RSS stabilized and GC pressure dropped by 70%.

This workflow — measure, snapshot, fix, test, monitor — prevented a costly incident and reduced operational CPU/Garbage Collection noise.

When to call in native-level tools

If you’ve ruled out JS-level retainers and still see unexplained native heap growth (or huge RSS while heapUsed remains small), look at:

Native addons or WebAssembly modules leaking memory (see discussions on hybrid edge and WebAssembly workflows).
Buffers (Buffer.alloc without zeroing or reuse) and large C++-side allocations.
Use node --trace-gc, strace, perf or eBPF and native malloc hooks to trace allocations; guidance on native-level cost tradeoffs is discussed in a CTO playbook on resource costs (storage & native considerations).

Actionable takeaways — checklist to run now

Reproduce the issue and collect baseline metrics (heapUsed, RSS, CPU).
Capture heap snapshots + allocation timeline and a CPU sampling profile for the problematic window.
Inspect dominator trees, find the object retaining the most memory, and trace back to code.
Apply focused fixes (WeakMap, LRU, remove listeners, clear timers, worker threads) and add regression tests.
Deploy with monitoring and alerts for heap growth and long GC pauses.

"Profiling is a conversation between your code and your tools. Let the traces tell you what to fix."

Final words — a trusted approach for 2026 and beyond

Memory and CPU problems are inevitable as apps grow. In 2026 the tooling has matured so that a disciplined workflow will usually find the root cause within an afternoon: reproduce, snapshot, analyze dominators, implement targeted fixes, and automate regression checks. Prevent leaks by design — prefer WeakMap for ephemeral associations, limit caches, always clean up listeners/timers, and offload heavy work when possible.

Start small: add one memory baseline probe this week and a single CI memory check. You'll catch issues earlier and make incident response a lot less painful.

Call to action

Run the checklist above on your most critical service this week. If you want a tailored checklist for your stack (React/Angular/Vue, Node/Express, serverless), leave your stack in the comments or subscribe for a downloadable cheat sheet with commands, sample scripts, and CI snippets.

Unknown

Contributor

Senior editor and content strategist. Writing about technology, design, and the future of digital media. Follow along for deep dives into the industry's moving parts.