Performance-Optimierung mit Claude Code: Messen und Core Web Vitals

Performance-Optimierung bedeutet nicht, eine Web-App irgendwie schneller wirken zu lassen. Es geht darum, Wartezeit, blockierte Interaktionen, Layout-Verschiebungen und verschwendete Serverressourcen messbar zu machen und dann gezielt zu senken.

Claude Code ist dafür nützlich, weil es Code lesen, Engpässe eingrenzen, kleine Patches vorschlagen und Verifikationsschritte formulieren kann. Der Ablauf bleibt entscheidend: erst messen, dann eine Hypothese bilden, eine Sache ändern und mit demselben Verfahren erneut messen.

Als offizielle Grundlagen dienen web.dev Core Web Vitals, Lighthouse docs und die MDN Performance API.

Schnell Erst Definieren

Web-Performance besteht aus mehreren Metriken. LCP, Largest Contentful Paint, misst wann der Hauptinhalt sichtbar wird. INP, Interaction to Next Paint, misst die Reaktionsfähigkeit nach Klick, Tap oder Tastatureingabe. CLS, Cumulative Layout Shift, misst unerwartete Layout-Bewegungen.

Für Anwendungen zählen außerdem API-p75-Latenz, Anzahl der Datenbankabfragen, JavaScript-Bundlegröße, Bildtransfer und synchroner CPU-Aufwand im Browser. Durchschnittswerte verstecken langsame Nutzer; p75 ist oft näher an der spürbaren Realität.

flowchart LR
  Measure["Messen"] --> Hypothesis["Hypothese"]
  Hypothesis --> Patch["Klein ändern"]
  Patch --> Verify["Erneut messen"]
  Verify --> Keep["Bewiesenes behalten"]

Metrik	Bedeutung	Erstes Ziel
LCP	Hauptinhalt sichtbar	2.5s oder weniger
INP	Reaktion auf Interaktionen	200ms oder weniger
CLS	Unerwartete Verschiebungen	0.1 oder weniger
API p75	Latenz, die viele Nutzer spüren	Pro Ansicht definieren
JS Transfer	JavaScript beim Start	Pro Route vergleichen

Bessere Eingaben Für Claude Code

Eine gute Anfrage enthält Symptom, Reproduktion, aktuelle Werte und Einschränkungen.

Die Seite /products in diesem Repository ist langsam.
Ziel ist weniger mobiles LCP und weniger p75 für /api/products.

Aktuelle Messungen:
- Lighthouse mobile Performance: 58
- LCP: 4.2s
- INP: 180ms
- CLS: 0.04
- /api/products p75: 920ms

Bitte:
1. Prüfe Bilder, Bundle, API und Datenbankzugriff.
2. Ändere nichts nur aus Vermutung; nenne Dateien und Belege.
3. Priorisiere kleine, messbare Änderungen.
4. Nenne die Befehle zur Prüfung nach der Änderung.

Passende interne Artikel sind der Claude Code Debugging Guide, React-Entwicklung mit Claude Code und der Claude Code Image Optimization Guide.

Ausführbares Messskript

Mit Node.js 18 oder neuer misst dieses Skript eine Seite oder API und gibt Durchschnitt und p75 aus.

// measure-url.mjs
import { performance } from "node:perf_hooks";

const url = process.argv[2] ?? "https://example.com/";
const runs = Number(process.argv[3] ?? 5);

async function measureOnce() {
  const start = performance.now();
  const res = await fetch(url, { cache: "no-store" });
  await res.arrayBuffer();
  return {
    status: res.status,
    ms: performance.now() - start,
  };
}

const samples = [];
for (let i = 0; i < runs; i += 1) {
  samples.push(await measureOnce());
}

samples.sort((a, b) => a.ms - b.ms);
const avg = samples.reduce((sum, s) => sum + s.ms, 0) / samples.length;
const p75Index = Math.floor((samples.length - 1) * 0.75);
const p75 = samples[p75Index].ms;

console.table(
  samples.map((sample, index) => ({
    run: index + 1,
    status: sample.status,
    ms: sample.ms.toFixed(1),
  }))
);
console.log(`avg=${avg.toFixed(1)}ms p75=${p75.toFixed(1)}ms`);

node measure-url.mjs http://localhost:3000/api/products 7

Gib diese Ausgabe Claude Code vor und nach dem Patch. So wird Performance-Arbeit reproduzierbar.

Realistische Use Cases

Fall	Häufige Ursache	Aufgabe für Claude Code
SaaS-Dashboard lädt langsam	Alle Widgets laden sofort; Chart-Bibliothek ist groß	Unwichtige Widgets verzögern und Chart-Code splitten
E-Commerce-Liste ist langsam	Große Bilder und N+1 für Bestand oder Reviews	Bildgrößen und include/select prüfen
Medienartikel hat schlechten LCP	Hero-Bild kommt spät; Werbeskripte laufen früh	Hauptbild priorisieren, Drittanbieter verzögern
Admin-Suche blockiert	Große Arrays synchron im Main Thread filtern	Komplexität senken, paginieren oder auslagern

N+1 bedeutet: Eine Liste wird geladen, danach startet für jede Zeile eine zusätzliche Abfrage. Caching bedeutet, ein Ergebnis kurzzeitig wiederzuverwenden. Private Daten, Preise, Berechtigungen und Bestände brauchen dabei klare Keys, TTLs und Invalidierung.

Ausführbares Cache-Beispiel

Dieses Express-Beispiel vergleicht einen absichtlich langsamen Endpoint mit einem gecachten Endpoint. In Produktion nutzt man oft Redis oder CDN, aber im Speicher ist der Effekt leicht sichtbar.

npm init -y
npm install express
node cached-api.mjs

// cached-api.mjs
import express from "express";
import { performance } from "node:perf_hooks";

const app = express();
const cache = new Map();
const ttlMs = 30_000;

async function loadProducts() {
  await new Promise((resolve) => setTimeout(resolve, 800));
  return [
    { id: 1, name: "Starter Plan", price: 1200 },
    { id: 2, name: "Pro Plan", price: 4800 },
  ];
}

async function cached(key, loader) {
  const now = Date.now();
  const hit = cache.get(key);
  if (hit && hit.expiresAt > now) return { data: hit.data, cache: "hit" };

  const data = await loader();
  cache.set(key, { data, expiresAt: now + ttlMs });
  return { data, cache: "miss" };
}

app.get("/api/products/raw", async (_req, res) => {
  const start = performance.now();
  const data = await loadProducts();
  res.json({ cache: "none", ms: performance.now() - start, data });
});

app.get("/api/products/cached", async (_req, res) => {
  const start = performance.now();
  const result = await cached("products", loadProducts);
  res.json({ ...result, ms: performance.now() - start });
});

app.listen(3000, () => {
  console.log("Open http://localhost:3000/api/products/raw");
});

node measure-url.mjs http://localhost:3000/api/products/raw 3
node measure-url.mjs http://localhost:3000/api/products/cached 3

Wenn du Claude Code um Caching bittest, definiere den Umfang: beliebte Produkte 30 Sekunden cachen, Bestand nicht cachen, userId in den Key aufnehmen.

Ausführbares Algorithmus-Beispiel

Nicht jeder Engpass ist Netzwerk. Schweres synchrones JavaScript kann INP verschlechtern. Hier ersetzt ein Set wiederholte includes-Scans.

// compare-lookup.mjs
import { performance } from "node:perf_hooks";

const a = Array.from({ length: 40_000 }, (_, i) => i);
const b = Array.from({ length: 40_000 }, (_, i) => i * 2);

function slowIntersection(left, right) {
  return left.filter((item) => right.includes(item));
}

function fastIntersection(left, right) {
  const rightSet = new Set(right);
  return left.filter((item) => rightSet.has(item));
}

function time(label, fn) {
  const start = performance.now();
  const result = fn();
  const ms = performance.now() - start;
  console.log(`${label}: ${ms.toFixed(1)}ms (${result.length} hits)`);
}

time("slow", () => slowIntersection(a, b));
time("fast", () => fastIntersection(a, b));

node compare-lookup.mjs

Häufige Fehler

Optimiere nicht nur für den Lighthouse-Score. Lighthouse ist Labordaten; echte Nutzer haben andere Geräte, Netze und Cache-Zustände. Ergänze Search Console, RUM und Serverlogs.

Führe keinen Cache ohne Korrektheitsregeln ein. Preise, Bestand, Berechtigungen und persönliche Daten brauchen Key, TTL und Invalidierung.

Setze useMemo nicht überall ein. React-Memoisierung gehört auf gemessene Hot Paths, nicht auf jede Komponente.

Priorisiere nicht jedes Bild. Above-the-fold-Bilder brauchen stabile Größen und manchmal Priority; Bilder weiter unten sollten meist lazy bleiben.

Splitte Bundles nicht blind. Nutze Claude Code Bundle Analysis und Claude Code Code Splitting, um Effekte pro Route zu vergleichen.

Regeln Für CLAUDE.md

## Performance rules
- Before optimizing, record the current metric and target metric.
- Prefer small, measurable changes over broad rewrites.
- Do not introduce shared cache for user-specific data.
- Avoid N+1 queries; use select/include or batching.
- Keep above-the-fold images sized and stable.
- After changes, report commands used for verification.

Diese Regeln halten Claude Code bei belegbaren Verbesserungen.

Consulting CTA

ClaudeCodeLab kann bestehende Web-Apps mit Claude Code prüfen, Core Web Vitals verbessern, API- und DB-Latenz trennen und ein praktisches Performance-Runbook erstellen. Für eine erste Analyse helfen Ziel-URL, Hauptseiten, Lighthouse-Ergebnis, Logs langsamer APIs und gewünschter Termin.

Praktisch Geprüft

Lokal bleibt /api/products/raw wegen der absichtlichen Verzögerung im Bereich von etwa 800ms. /api/products/cached fällt nach der ersten Anfrage auf wenige Millisekunden. compare-lookup.mjs zeigt ebenfalls einen deutlichen Vorteil für Set. Reale Projekte sind weniger sauber, aber die Methode bleibt: p75 messen, eine Sache ändern, identisch nachmessen.