# So vergleichen Sie die Leistung von React SSR

Ein nützlicher SSR-Benchmark beantwortet eine bestimmte Frage: Wie viel korrekte Arbeit kann die Anwendung innerhalb eines Ressourcenbudgets mit welcher Latenz und welchen Kosten erledigen? Allein die Zahl der Anfragen pro Sekunde lässt zu viel ungeklärt.

Diese Methode gilt für Versionen, Profile oder React-Laufzeiten. Es trennt HTTP-Messungen von Browser-Reisen und enthält ein k6-Beispiel zur Anpassung an eine Fixture-Route. Das Beispiel selbst ermittelt kein Leistungsergebnis.

## Definieren Sie eine richtige Antwort

Wählen Sie eine repräsentative Route: eine dynamische Liste, eine API oder eine Streaming-Seite. Korrigieren Sie das Datenvolumen, die Abhängigkeiten und die Authentifizierungsbedingungen. Eine Fixture-Route kann eine eindeutige Anforderungsmarkierung zurückgeben, um veraltete oder falsch geteilte Antworten zu erkennen.

Überprüfen Sie den Status, den Inhaltstyp und einen erwarteten Textkörperwert. Stellen Sie bei dynamischem SSR sicher, dass das Rendern tatsächlich erfolgt. Eine zwischengespeicherte statische Datei und eine frisch gerenderte Seite stellen unterschiedliche Arbeitslasten dar.

## Machen Sie Umgebungen vergleichbar

Identifizieren Sie die Optionen für Commit, Artefakte, Knoten, React, Betriebssystem und Compiler. Behalten Sie auf einem bestimmten Computer die gleichen ausführbaren Knoten- und Anwendungsabhängigkeiten bei. Verwenden Sie Produktions-Builds und zeichnen Sie Cache- und Komprimierungseinstellungen auf.

Legen Sie Budgets für die gesamte Gruppe fest, einschließlich der Mitarbeiter und etwaiger Stellvertreter. Erklären Sie die Topologie: Zwei Prozesse hinter einem Proxy benötigen im Vergleich zu einem direkten Server Kontext. Bevorzugen Sie eine separate Lastgeneratormaschine und überwachen Sie, ob diese gesättigt ist.

## Erstellen Sie eine dynamische Fixture-Route

Erstellen Sie in einer App Router-Testanwendung app/bench/page.jsx mit diesem Inhalt. Die Markierung variiert je nach Anforderung und das dynamische Rendering ist explizit. Dieses Beispiel leistet sehr wenig Arbeit; Ersetzen Sie es durch repräsentatives Rendering, wenn Sie ein Geschäftsszenario bewerten.

Behalten Sie dieselbe Quelle für die zu vergleichenden Laufzeiten bei. Eine Markierung allein beweist nicht die Isolation aller Daten: Fügen Sie separate Sitzungen und anwendungsspezifische Behauptungen hinzu, wenn Benutzer Teil des Szenarios sind.

```jsx
export const dynamic = "force-dynamic";

export default async function Benchmark({ searchParams }) {
  const { id = "missing" } = await searchParams;
  return <main>Benchmark marker: {id}</main>;
}
```

## Fügen Sie dem Lastgenerator eine Validierung hinzu

Speichern Sie dieses Beispiel als bench.js. Es erwartet eine /bench-Fixture-Route, die den ID-Abfrageparameter in seinem HTML wiedergibt. Erstellen Sie diese Route in Ihrer Testanwendung. Weder Next.js noch PRNext liefern es automatisch. BASE_URL zielt auf eine von Ihnen kontrollierte Testinstanz ab.

Der Prüfschwellenwert macht die Ausführung ungültig, wenn die Validierung einer Antwort fehlschlägt. Weiterleitungen sind deaktiviert, um zu vermeiden, dass stillschweigend eine andere Seite gemessen wird. Dies ist ein Beispiel für eine geschlossene Parallelität: Wenn der Server langsamer wird, wartet jeder virtuelle Benutzer länger. Es wird keine feste Ankunftsrate simuliert.

```js
import http from "k6/http";
import { check } from "k6";

export const options = {
  vus: 16,
  duration: "60s",
  thresholds: { checks: ["rate==1"], http_req_failed: ["rate==0"] }
};

export default function () {
  const id = `request-${__VU}-${__ITER}`;
  const base = __ENV.BASE_URL || "http://127.0.0.1:3000";
  const response = http.get(`${base}/bench?id=${id}`, { redirects: 0 });
  check(response, {
    "status 200": r => r.status === 200,
    "HTML response": r => String(r.headers["Content-Type"]).includes("text/html"),
    "fresh marker": r => typeof r.body === "string" && r.body.includes(id)
  });
}
```

## Trennen Sie das Aufwärmen von den gemessenen Fenstern

Führen Sie bei installiertem k6 eine separate Aufwärmphase und anschließend mehrere gemessene Fenster durch. Ändern Sie die Reihenfolge der Kandidaten und behalten Sie die Ausgabe jedes Laufs bei. Der Befehl verwendet die Syntax der POSIX-Shell-Umgebung. Passen Sie die BASE_URL-Zuweisung in PowerShell an.

Der Generator verfügt über ein eigenes Netzwerk und kostet CPU. Halten Sie die Parameter für beide Kandidaten identisch und zeichnen Sie konkurrierende Serveraktivitäten auf. Wiederholte Fenster helfen bei der Beschreibung der Variabilität, beseitigen jedoch keine Topologieverzerrung und machen eine nicht repräsentative Vorrichtung nicht repräsentativ.

```sh
BASE_URL=http://127.0.0.1:3000 k6 run --duration 10s bench.js
BASE_URL=http://127.0.0.1:3000 k6 run --summary-export result-a.json bench.js
```

## Lesen Sie Durchsatz, Latenz, CPU und Speicher zusammen

Der p95 ist eine Dauer, unterhalb derer 95% der erfassten Anfragen abgeschlossen werden. In k6 schließt http_req_duration Phasen wie die DNS-Suche und den ersten Verbindungsaufbau aus. Benennen Sie die Metrik, anstatt sie Geschwindigkeit zu nennen.

Berechnen Sie die CPU-Arbeit der Gruppe pro korrekter Antwort separat über das gemessene Fenster: das CPU-Delta der Gruppe dividiert durch validierte Antworten. HTTP p95 ist kein CPU-Verbrauch. Gruppenspeicher und Prozessbaum-PSS mit der angegebenen Methode aufzeichnen. Machen Sie ein Fenster mit falschem Inhalt ungültig, bevor Sie die Leistung vergleichen.

## Fügen Sie eine Browser-Reise hinzu

Ein Kunde kann HTML schnell empfangen und trotzdem auf die Flüssigkeitszufuhr warten. Messen Sie Navigation, Rücknavigation und eine Geschäftsinteraktion separat. Überprüfen Sie, ob Zähler, Sitzungen oder Formularstatus während der gesamten Reise korrekt bleiben.

In unserem VPS-Vergleich führen Servergewinne nicht zu Gewinnen bei allen Browsermessungen. Durch die Veröffentlichung dieser Unterschiede wird die Auswertung nützlicher. Bewahren Sie das Protokoll, die Rohausgabe und die Einschränkungen neben den Diagrammen auf.

[Lesen Sie unsere SSR- und Navigationskampagne auf zwei VPS-Geräten](/de/blog/prnext-vs-nextjs-vps-benchmarks)

## Sources

[k6: built-in metrics](https://grafana.com/docs/k6/latest/using-k6/metrics/reference/)

[k6: checks](https://grafana.com/docs/k6/latest/using-k6/checks/)

[k6: thresholds](https://grafana.com/docs/k6/latest/using-k6/thresholds/)

[Linux: cgroup v2](https://docs.kernel.org/admin-guide/cgroup-v2.html)

[Node.js: process.memoryUsage()](https://nodejs.org/api/process.html#processmemoryusage)

Veröffentlicht: 2026-10-30

Geändert: 2026-10-30

Autor: PRNext

---

Sprache: de

Canonical: https://prnext.dev/de/blog/benchmark-react-ssr

Index: https://prnext.dev/llms.txt