DevTools: look inside your app

Chrome DevTools is built into the browser and works on any site, including published apps. It shows you the DOM, the requests, what is stored in the browser, how much the page consumes and what stays in memory. Angular DevTools is a separate extension that adds an “Angular” tab with the component tree, the profiler, the injectors and the routes.

The steps below use the exact button names from Chrome DevTools, taken from its source code. Each section has an exercise you can do right on this page.

Open DevTools and find any panel

• Open DevTools with F12 or Ctrl+Shift+I (Windows, Linux), or Cmd+Option+I (Mac). Or right-click the page → Inspect.
• Panels are tabs at the top: Elements, Console, Sources, Network, Performance, Memory, Application. The ones that do not fit are under ».
• The fastest way to anything is the command menu, with Ctrl+Shift+P or Cmd+Shift+P. Type “memory” and choose Show Memory, or “performance monitor” and choose Show Performance monitor.
• Esc opens and closes the bottom drawer, with the Console. That way you see the console next to any other panel.

Practise on this page

Keep DevTools open next to the page. Each card says what you press here and what you look for there.

Elements: what Angular rendered

Elements shows the DOM as it is now, not the HTML the server sent. A few things Angular leaves in it:

• The root element (<app-root>) carries an ng-version attribute with the exact Angular version. On this site: 22.2.2.
• The _nghost-ng-c… and _ngcontent-ng-c… attributes come from style encapsulation (Emulated mode). In the Styles pane on the right, selectors look like .btn[_ngcontent-ng-c…].
• The empty <!----> comments are Angular’s anchors for @if, @for and @defer: the place where it inserts or removes content.
• The selected element is available in the Console as $0. Attributes and text that change flash briefly in Elements: that is how you see what Angular updates.

Console: the ng utilities (development only)

In your own app started with ng serve, Angular puts a global ng object on the page. Select an element in Elements, then in the Console:

// Elements: select an element; in the Console it is $0 (development only)
ng.getComponent($0)          // the component whose host is $0
ng.getOwningComponent($0)    // the component whose template contains $0
ng.getDirectives($0)         // the directives on $0
ng.getInjector($0)           // the element injector: .get(SomeService)
ng.getListeners($0)          // the listeners Angular added to $0
ng.getRootComponents()       // the root components

const c = ng.getComponent($0);
c.count.set(42);             // a signal is written directly; Angular renders on its own
c.title = 'Test';            // a plain property needs applyChanges
ng.applyChanges(c);

On a production build these functions do not exist. That is not a bug: they are removed on purpose so they do not weigh down the app.

Network: what the app requests

Network only records while it is open. If you open it after the page has loaded, reload the page.

• The filters at the top (Fetch/XHR, JS, CSS, Img…) and the text box leave only the requests you care about.
• Click a request: Headers (URL, status, headers), Payload (what you sent), Preview and Response (what came back), Initiator (which code started it), Timing (where the time went).
• Keep log (in older versions: Preserve log) keeps the list across navigation and reloads. Disable cache skips the cache while DevTools is open.
• The Throttling menu simulates a slower network: Fast 4G, Slow 4G, 3G or Offline. That way you see skeletons, loading states and what happens without a network.

Application: what the app keeps in the browser

• Storage → Local storage / Session storage → the site’s address: the keys and values, which you can edit or delete.
• Cookies, IndexedDB and Cache storage are in the same place. Cache storage is where a Service Worker keeps files for offline use.
• The Service workers section shows the active worker. Update on reload forces the new version on every reload, and Bypass for network skips it. Both are handy while you work on it.
• Storage → Clear site data deletes everything the site saved. It is the safest way to test a “first visit”.

Performance monitor: the quick check

Before any snapshots, look at live numbers:

1. Command menu (Ctrl/Cmd+Shift+P) → “performance monitor” → Show Performance monitor. It opens at the bottom, in the drawer.
2. Watch JS heap size, DOM nodes and JS event listeners. Click a name to show or hide its chart.
3. In the lab below, with the fixes unchecked, press Open and close 10 times. JS event listeners grows by 10 and stays there. Press Clean up the zombies: it goes back down. With all fixes checked, it does not grow at all.

Memory: a leak found step by step

The lab from the memory leaks lesson, here, so you have something to measure. Every widget closed with the fixes unchecked leaves behind a timer, a listener and a subscription that keep the component in memory.

Heap snapshot and Comparison

1. Open the Memory panel. Under Select profiling type choose Heap snapshot.
2. Click the bin icon, Collect garbage, then Take snapshot. Snapshot 1 appears on the left.
3. On the page, with the fixes unchecked, press Open and close 10 times and wait for it to finish.
4. Again Collect garbage and Take snapshot: Snapshot 2 appears.
5. With Snapshot 2 selected, switch the first menu in the top bar from Summary to Comparison. The menu next to it shows what you compare against: Snapshot 1.
6. Type a name from the table below into Filter by class and look at the # New and # Delta columns.
7. Press Clean up the zombies, take Snapshot 3 and compare it with Snapshot 2: the same rows now show up under # Deleted.

Who holds the object: Retainers

Expand a row and click an instance. The Retainers pane at the bottom shows who keeps it alive: the top rows are the direct references, and expanding them walks up the chain towards something long-lived (Window, a listener, a timer). The Distance column tells you how many steps away window is. The leak is the link your code should have broken on destroy.

More direct: Detached elements

1. In Memory → Select profiling type choose Detached elements.
2. Repeat the action on the page, then press Get detached elements.
3. The list shows elements removed from the page but still referenced from JavaScript. Here: one <app-leaky-widget> for every closed widget.

Performance: what happens over time

• Record records while you do something on the page. Record and reload reloads the page and records the startup.
• Check Show memory timeline to see JS heap, documents, nodes and listeners on the same axis. A leak looks like a staircase that goes up and never comes down.
• In development, Angular can add its own Angular track with components, change detection and hooks. Turn it on with ng.enableProfiling() in the Console, before Record.

// in the Console, in your app started with ng serve:
ng.enableProfiling();

// or in main.ts, to capture the startup too:
import { enableProfiling } from '@angular/core';

enableProfiling();
bootstrapApplication(App, appConfig);

Angular DevTools

The extension sees the app the way Angular sees it: components, inputs, signals, injectors, routes.

1. Install Angular DevTools from the Chrome Web Store (there is a Firefox version too).
2. Start your app with ng serve, open DevTools and look for the Angular tab, possibly under ». Extensions do not run on the browser’s “New tab” page.
3. On a production build, this site included, you will only see the message “We detected an application built with production configuration”. That is expected.

• $ng0 in the Console is the component currently selected in Angular DevTools, $ng1 the one before it.
• The inspect icon in the extension’s corner: move the mouse over the page and see which component is there.
• Double-clicking a component takes you to its element in Elements; the icon at the top right takes you to its source in Sources.
• Show Signal Graph, in the header of the properties pane, draws the component’s signals, computeds and effects and who reads whom (Angular 19+). Give them a debugName so they have readable names.

The usual sources of leaks and how to close each one are in Memory leaks. What to do once you have found what is slow: Performance and Change detection.

Common pitfalls

• Looking for your class name on a production build. It is not there: search by tag or native type, or start the app with ng serve.
• Comparing snapshots without Collect garbage first: the heap goes up and down on its own, and small differences mean nothing.
• Repeating the action only once. A leak is a number that grows by the same step on every repetition. Repeat 10 times and look for +10.
• Opening Network after the page has loaded and thinking nothing was requested. Network only records while it is open: reload the page.

Cheat sheet

F12 · Ctrl+Shift+I · Cmd+Option+I            open DevTools
Ctrl+Shift+C · Cmd+Shift+C                   pick an element on the page
Ctrl+Shift+P · Cmd+Shift+P                   the command menu
Esc                                          the drawer with the Console

Network       Fetch/XHR · Keep log · Disable cache · Throttling
Application   Storage → Local storage · Service workers · Clear site data
Perf monitor  JS heap size · DOM nodes · JS event listeners
Memory        Heap snapshot → Take snapshot → Comparison → Filter by class
Memory        Detached elements → Get detached elements
Performance   Record · Record and reload · Show memory timeline

development only:
  ng.getComponent($0) · ng.applyChanges(c) · ng.enableProfiling()
  Angular DevTools: Components · Profiler · Injector Tree · Router Tree · $ng0