Demo
Tool-Demo-Seite
Was ist SSR?
Diese Demo-Seite ist kein Endnutzer-Werkzeug, sondern eine kleine Referenzroute für serverseitiges Rendering. Sie zeigt, wie eine Next.js-App-Router-Seite Daten auf dem Server abrufen, das Ergebnis direkt in die erste HTML-Antwort rendern und gleichzeitig die lokalisierten Texte für die aktuelle Sprache laden kann. Dadurch eignet sie sich zum Prüfen gemeinsamer Infrastruktur: Umgebungsvariablen, signierte Server-Fetches, API-Antwortformat, Locale-Routing und Übersetzungsauflösung. Wenn diese Seite funktioniert, ist der grundlegende SSR-Pfad intakt, bevor eine komplexere Tool-Seite untersucht wird. Wenn sie fehlschlägt, liegt die Ursache wahrscheinlich in gemeinsamer Serverkonfiguration oder API-Erreichbarkeit. Die Seite sollte bewusst einfach bleiben, damit sie als Smoke-Test nach Deployments und Framework-Änderungen taugt.
Anleitung
Anleitung
- Die Seite ruft die Back-End-API automatisch serverseitig auf.
- HTML enthält vorgerenderte Inhalte; keine Client-Anfrage nötig.
- Anzeigen der von der API zurückgegebenen Daten.
- Ideal für Seiten, die SEO-Optimierung benötigen.
Entwicklungshinweise
- Diese Seite eignet sich als Smoke-Test für SSR, Sprachladung, signierte Serveranfragen und API-Konnektivität.
- Wenn diese Seite nicht funktioniert, prüfen Sie zuerst die gemeinsame Serverkonfiguration, bevor Sie eine bestimmte Tool-Seite debuggen.
Anwendungsfälle
Technisches Prinzip
Diese Demo-Seite basiert auf Next.js 16 App Router und verwendet standardmäßig serverseitiges Rendering (SSR). Wenn ein Benutzer die Seite aufruft, führt der Node.js-Server zuerst die React-Komponente aus, ruft die Back-End-API zur Datenbeschaffung auf und liefert dann das vollständig gerenderte HTML in einer einzigen Antwort an den Browser zurück. Der Browser beginnt sofort mit dem Parsen und Rendern des HTML, sodass Benutzer den vollständigen Inhalt im ersten Frame sehen, ohne auf das Herunterladen und Ausführen von JavaScript warten zu müssen. Dies steht im Gegensatz zum traditionellen clientseitigen Rendering (CSR). Bei CSR liefert der Server nur eine nahezu leere HTML-Hülle und einen JS-Link zurück; der Browser muss das JS-Bundle herunterladen, die Framework-Initialisierung durchführen, APIs zum Abrufen der Daten aufrufen und erst dann die Seite rendern. Aus Sicht des Benutzers ist das ein „Bildschirm, der eine Weile leer bleibt”, und für Suchmaschinen-Crawler ist es noch schlimmer – die meisten Crawler führen kein JavaScript aus und sehen nur die leere Hülle. Nach dem SSR injiziert Next.js außerdem ein JavaScript-Stück für die „Hydration”: Das vorhandene DOM wird mit dem React-Komponentenbaum verknüpft und Event-Listener gebunden, sodass die Seite interaktiv wird. Der vollständige Ablauf ist HTML-Parsen -> CSS-Laden -> JS-Download -> Hydration -> Interaktiv. Von den drei Core Web Vitals sind LCP (Largest Contentful Paint) und CLS (Cumulative Layout Shift) unter SSR in der Regel besser, während INP (Interaction to Next Paint) von der Hydration-Geschwindigkeit und der Qualität der Event-Handler-Implementierung abhängt.
- Next.js App Router: Seiten im App Router sind standardmäßig Server Components, die auf dem Server laufen und automatisch HTML zurückliefern – ohne zusätzliche Konfiguration.
- SSR vs. CSR: SSR liefert schnelles First Paint und SEO-Freundlichkeit auf Kosten von Serverressourcen; CSR eignet sich für interne Dashboards und andere interaktive Szenarien ohne SEO-Bedarf.
- First-Paint-Ablauf: HTML-Parsen -> CSS-Laden und Rendern -> JS-Download und Ausführung -> React-Hydration -> Seite interaktiv; jeder Schritt beeinflusst LCP.
- SEO-Crawler-Freundlichkeit: Mainstream-Crawler wie Googlebot und Bingbot lesen den HTML-Text direkt; die SSR-Ausgabe von vollständigem Inhalt garantiert Crawling-Abdeckung.
- Web-Vitals-Schwellenwerte: LCP < 2,5 s, INP < 200 ms, CLS < 0,1 sind Googles empfohlene „gute” Schwellenwerte; SSR erleichtert das Erreichen von LCP und CLS.
- Signierte Anfragen: Die Demo-Seite ruft die Back-End-API über serverApiFetch auf dem Server auf und überträgt automatisch X-Timestamp, X-Nonce und X-Sign zur Authentifizierung.
Beispiele
SSR (Server-Side Rendering)
// app/page.tsx (default Server Component)
export default async function Page() {
const data = await fetch('/api/info').then(r => r.json());
return <div>{data.title}</div>;
}
// Das HTML enthält bereits direkt <div>tatsächlicher Inhalt</div>CSR (Client-Side Rendering)
'use client';
import { useEffect, useState } from 'react';
export default function Page() {
const [data, setData] = useState(null);
useEffect(() => {
fetch('/api/info').then(r => r.json()).then(setData);
}, []);
return <div>{data?.title || 'Loading...'}</div>;
}
// Das initiale HTML enthält nur <div>Loading...</div>First-Paint-Geschwindigkeitsvergleich
# SSR
FCP: 0,4s LCP: 0,8s TTI: 1,2s
SEO: Crawler erhalten den vollständigen Inhalt direkt
# CSR
FCP: 0,6s LCP: 1,8s TTI: 2,4s
SEO: Crawler müssen JS ausführen, um den Inhalt zu erhaltenFAQ
Was demonstriert diese Demo-Seite eigentlich?
Es ist eine Referenz-Route für Server-Side Rendering (SSR), die zeigt, wie eine Next.js-App-Router-Seite Daten serverseitig holen, das Ergebnis in die erste HTML-Antwort einbetten und trotzdem die richtigen lokalisierten Beschriftungen laden kann. Es ist kein Endbenutzer-Werkzeug – es ist ein Smoke-Test für Entwickler.
Werden die Daten serverseitig oder im Browser geholt?
Serverseitig. Die Seite ruft serverApiFetch (mit den signierten Request-Headern aus src/lib/sign.ts) innerhalb der React Server Component auf, sodass der Browser eine HTML-Seite erhält, die die Daten bereits enthält. Beim ersten Laden gibt es keinen clientseitigen Fetch.
Warum zeigt die Seite manchmal veraltete Daten?
Next.js cached die SSR-Antwort je nach revalidate-Einstellung. Brauchst du bei jedem Request frische Daten, setze 'export const dynamic = "force-dynamic"' oder übergib {cache: 'no-store'} an den Fetch. Die Demo-Route nutzt das Standardverhalten, um das Beispiel einfach zu halten.
Kann ich dieses Muster für meine eigene Seite kopieren?
Ja – genau dafür ist es gedacht. Die Route zeigt, wie man getTranslations aus next-intl mit einem serverseitigen Daten-Fetch kombiniert und das Ergebnis an eine Client Component für Interaktivität weitergibt. Kopiere layout.tsx und page.tsx und tausche die Datenquelle aus.
Wozu Request-Signing für eine interne API?
X-Timestamp / X-Nonce / X-Sign blockieren Replay-Angriffe und stellen sicher, dass Anfragen aus dem öffentlichen Web tatsächlich von einem vertrauten Client stammen. Der Signaturschlüssel ist pro Sitzung für angemeldete Nutzer und sonst ein Standardwert; siehe src/lib/sign.ts und src/lib/fetch.ts für die Implementierung.
Existiert diese Seite im Produktiv-Build?
Sie ist Teil der ausgelieferten App zur Referenz, aber nicht von der Startseite oder Tool-Liste verlinkt und wird nicht als Nutzer-Tool beworben. Behandle sie als Entwicklerdokumentation in Form einer Route.
Was sollte ich anschauen, wenn ich das Projektlayout lernen will?
Beginne mit der layout.tsx und page.tsx dieser Seite, dann lies src/i18n.ts (Locale-Konfiguration), src/i18n/request.ts (globales Laden von Übersetzungen), src/lib/load-page-messages.ts (Übersetzungen pro Seite) und src/lib/fetch.ts (Wrapper für signierte Requests).