Performance 2. Mai 2026 12 min Lesezeit

Performance Optimierung mit Claude Code: Web & Node.js 2026

Performance-Probleme sind schwer zu finden: sie zeigen sich erst unter Last, ihre Ursache liegt oft weit vom Symptom. Claude Code analysiert Lighthouse-Reports, Flamegraphs und SQL-Explain-Plans — und findet systematisch was du manuell übersehen hättest.

Core Web Vitals mit Claude Code verbessern

LCP

Largest Contentful Paint
Ziel: < 2.5s

FID/INP

Interaction to Next Paint
Ziel: < 200ms

CLS

Cumulative Layout Shift
Ziel: < 0.1

WebLighthouse-Report analysieren

# Prompt für Lighthouse-Analyse:
Hier ist mein Lighthouse-Report (JSON):
[lighthouse output einfügen oder: "Führe Lighthouse auf https://example.com aus"]

Analysiere:
1. Was sind die Top-3 Performance-Bottlenecks?
2. Welche Optimierungen haben den größten Impact? (Quick Wins first)
3. Wo ist der LCP-Element und warum lädt er langsam?
4. Welche Resources blockieren das Rendering?
5. Zeige mir konkret welche Zeilen Code ich ändern muss.

WebBundle-Größe reduzieren

Zu große JavaScript-Bundles sind der häufigste LCP-Killer. Claude Code analysiert Webpack/Vite Bundle-Stats:

# Prompt für Bundle-Analyse:
Hier ist mein Webpack Bundle Analyzer Output:
[bundle stats als JSON oder Screenshot-Beschreibung]

Mein Haupt-Bundle ist 1.2MB gzipped. Ziel: unter 400KB.

Analysiere:
1. Welche Libraries machen den größten Teil aus?
2. Gibt es Tree-Shaking-Probleme? (Ganze Bibliothek importiert statt nur was nötig)
3. Welche Packages haben kleinere Alternativen?
4. Was kann lazy-loaded werden?

❌ Vorher — 1.2MB

import _ from 'lodash'
import * as icons from '@heroicons/react'
import moment from 'moment'

✅ Nachher — 180KB

import debounce from 'lodash/debounce'
import { HomeIcon } from '@heroicons/react/24/outline'
import { format } from 'date-fns'

Node.js Performance-Bottlenecks

Node.jsEvent-Loop-Blockierung finden

# Problem: Event Loop blockiert → alle Requests werden langsam
# Prompt:
Mein Node.js-Server wird unter Last langsam.
clinic.js doctor zeigt: "Event Loop is consistently blocked"

Analysiere diesen Code-Ausschnitt auf Event-Loop-Blocking:
[Code einfügen]

Häufige Ursachen:
- Synchrone Datei-Operationen (fs.readFileSync)
- Schwere JSON.parse/stringify von großen Objekten
- Crypto-Operationen ohne Worker Threads
- CPU-intensive Berechnungen ohne setImmediate-Yielding

# Claude Code findet und fixt:
# VORHER — blockiert Event Loop
function hashPassword(password) {
  return crypto.createHash('sha256').update(password).digest('hex');
}

# NACHHER — async, blockiert nicht
import { scrypt, randomBytes } from 'node:crypto';
import { promisify } from 'node:util';
const scryptAsync = promisify(scrypt);

async function hashPassword(password) {
  const salt = randomBytes(16);
  const hash = await scryptAsync(password, salt, 64);
  return `${salt.toString('hex')}:${hash.toString('hex')}`;
}

Node.jsFlamegraph analysieren

# Flamegraph erzeugen:
npm install -g 0x
0x -- node server.js
# Öffnet interaktiven Flamegraph im Browser

# Dann: Screenshot an Claude Code:
Analysiere diesen Flamegraph. Erkläre:
1. Welche Funktion nimmt die meiste CPU-Zeit?
2. Warum wird sie so oft aufgerufen?
3. Ist die Zeit in V8-Internals (optimize/deoptimize)?
4. Gibt es einen heißen Pfad der vereinfacht werden könnte?

Datenbankabfragen optimieren

DatabaseEXPLAIN ANALYZE auswerten

# PostgreSQL EXPLAIN ANALYZE → Claude Code:
Diese Query braucht 2.3 Sekunden auf 5M Rows.
EXPLAIN ANALYZE Output:

Seq Scan on orders (cost=0.00..125840.00 rows=4000000)
  Filter: (status = 'completed' AND created_at > '2026-01-01')
  Rows Removed by Filter: 4500000
Planning Time: 2.5 ms
Execution Time: 2342.3 ms

Analysiere und schlage den optimalen Index vor.

# Claude Code antwortet:
# Problem: Sequential Scan über 5M Rows
# Fix: Composite Partial Index

CREATE INDEX CONCURRENTLY idx_orders_completed_recent
ON orders (created_at DESC)
WHERE status = 'completed';

# CONCURRENT = kein Table Lock in Production!
# Nach Index: Execution Time → ~12ms

React Performance mit Claude Code

# Re-Render-Analyse Prompt:
Meine React-Komponente re-rendert zu oft.
React DevTools Profiler zeigt 50+ Re-Renders pro Sekunde.

Analysiere diesen Komponenten-Code auf:
1. Fehlende useMemo/useCallback (neue Referenzen bei jedem Render)
2. Context-Provider zu weit oben im Tree
3. Unnötige State-Updates (setState mit gleichem Wert)
4. Fehlende React.memo für Pure Components

[Komponenten-Code einfügen]

❌ Vorher — 50+ Re-Renders/s

const handler = () => doSomething();
const data = items.filter(i => i.active);
Neue Referenzen bei jedem Render → Child re-rendert immer

✅ Nachher — 2-3 Re-Renders/s

const handler = useCallback(() => doSomething(), []);
const data = useMemo(() => items.filter(i => i.active), [items]);

Performance-Workflow: Messen → Analysieren mit Claude Code → Eine Optimierung → Messen. NIEMALS blind optimieren ohne vorher zu messen. Premature Optimization ist die Wurzel vieler Probleme.

Performance-Modul im Kurs

Im Claude Code Mastery Kurs gibt es ein Performance-Modul: Lighthouse-Analyse, Node.js Profiling mit 0x, N+1-Problem-Erkennung, React Re-Render-Optimierung — mit vollständigen Analyse-Workflows.

14 Tage kostenlos testen →