Client-Side Rendering (CSR): Definition und Abwägungen

Was ist Client-Side Rendering (CSR)?

Beim Client-Side Rendering (CSR) baut der Browser das HTML der Seite per JavaScript auf, statt es fertig vom Server zu erhalten. Der Server liefert eine kleine HTML-Hülle und ein JavaScript-Bundle; das Skript holt Daten, meist von einer API, und erzeugt den Inhalt im DOM. MDN beschreibt es als Gegenstück zum Server-Side Rendering und weist darauf hin, dass sich beide in einer Anwendung kombinieren lassen.

So funktioniert Client-Side Rendering

1. Der Browser ruft eine URL ab und erhält ein minimales HTML-Dokument, oft nur einen leeren Container und Script-Tags.
2. Er lädt das JavaScript-Bundle, parst es und führt es aus.
3. Die App fragt ihre Daten bei einer API ab.
4. Die App baut das DOM auf und der Nutzer sieht den Inhalt.
5. Weitere Navigation bleibt im Browser: Die App wechselt Ansichten und lädt nur Daten, keine ganzen Seiten. So arbeitet eine Single-Page-App.

Beispiel

Ein Dashboard mit React lädt eine HTML-Datei von wenigen hundert Byte. Der Besucher sieht eine leere Seite oder einen Spinner, bis das Bundle geladen, die API geantwortet und die Diagramme gezeichnet sind. Der Wechsel zwischen Tabs fühlt sich danach sofort an, weil nur JSON über das Netz geht.

Vorteile

• Schnelle Navigation in der App. Nach dem ersten Laden wechseln Ansichten ohne vollständiges Neuladen.
• Hohe Interaktivität. Dashboards, Editoren und Tools passen zu einer App, die im Browser lebt.
• Einfaches Hosting. Hülle und Bundle sind statische Dateien, die jedes CDN ausliefern kann; nur die API braucht Server.

Nachteile

• Späterer erster Inhalt. Nichts Sinnvolles erscheint, bevor JavaScript gelaufen ist. web.dev weist darauf hin, dass die JavaScript-Menge mit der App wächst, was INP verschlechtern kann, und dass CSR auf Mobilgeräten schwer schnell zu halten ist.
• SEO braucht Sorgfalt. Google verarbeitet JavaScript-Seiten in drei Phasen: Crawling, Rendering und Indexierung. Seiten warten in einer Render-Warteschlange, "ein paar Sekunden, es kann aber länger dauern" (sinngemäß aus Google Search Central). Google nennt Server-Side Rendering oder Pre-Rendering weiterhin eine gute Idee, weil nicht alle Bots JavaScript ausführen.
• Abhängig vom Gerät. Ein großes Bundle zu parsen und auszuführen dauert auf einem langsamen Smartphone länger als auf einem Entwickler-Laptop.

Häufige Fehler

• Ein riesiges Bundle ausliefern. Teilen Sie den Code nach Route und laden Sie nach, was der erste Bildschirm nicht braucht.
• Daten als Wasserfall laden. Eine Komponente, die auf ihre Elternkomponente wartet, bevor sie Daten anfragt, kostet pro Ebene einen vollen Roundtrip.
• noindex in die HTML-Hülle setzen und per JavaScript entfernen. Google kann das Rendering bei noindex überspringen, sodass das Entfernen nie ausgeführt wird.
• Nur auf schneller Hardware testen. Prüfen Sie mit gedrosselter CPU und Netzwerk oder auf echten Mittelklasse-Geräten.
• Kein aussagekräftiges HTML für wichtige Seiten. Marketing- und Inhaltsseiten fahren meist besser mit statischer Generierung oder Server-Rendering, die clientgerenderte App liegt hinter dem Login.

CSR, SSR und SSG im Vergleich

Es geht darum, wann das HTML entsteht. Rendering kann im Browser (CSR), bei jeder Anfrage auf dem Server (SSR) oder beim Build (SSG) stattfinden. Frameworks wie Next.js mischen das je Seite, und Hydration macht das servergenerierte HTML danach interaktiv. Eine öffentliche Seite, die in der Suche gefunden werden soll, passt schlecht zu reinem CSR; ein Tool hinter dem Login passt oft gut.

CSR-Apps testen und überwachen

Labor- und Felddaten sind wichtig, weil der Browser die Arbeit macht. Das Page-Speed-Monitoring von LoadFocus führt geplante Lighthouse-Audits und Core-Web-Vitals-Prüfungen aus 25 Cloud-Regionen aus und warnt, wenn eine Seite langsamer wird; der Core-Web-Vitals-Checker liefert einen einmaligen Wert, und die Anleitung zum Monitoring der Core Web Vitals mit Alerts und Berichten erklärt die Einrichtung. Die API hinter der App ist ein eigenes Thema: Ein JMeter- oder k6-Lasttest belastet ihre Endpunkte, nicht das Rendering im Browser.

Häufige Fragen: Client-Side Rendering

Was ist der Unterschied zwischen CSR und SSR?

Bei CSR baut der Browser das HTML mit JavaScript auf. Bei SSR sendet der Server HTML, das für diese Anfrage schon fertig ist. SSR zeigt Inhalt meist früher; CSR macht die spätere Navigation in der App schneller.

Ist Client-Side Rendering schlecht für SEO?

Nicht automatisch. Google kann JavaScript rendern, aber Seiten warten in einer Render-Warteschlange, und nicht alle Bots führen Skripte aus. Für Seiten, die ranken sollen, sind Server-Rendering oder Pre-Rendering die sicherere Wahl.

Welche Frameworks nutzen Client-Side Rendering?

React, Angular und Vue erzeugen standardmäßig Single-Page-Apps, die im Browser rendern. Meta-Frameworks wie Next.js und Nuxt ergänzen Server-Rendering und statische Generierung.

Schadet CSR den Core Web Vitals?

Es kann. Ein großes Bundle verzögert den Hauptinhalt und blockiert den Main-Thread, was Laden und INP beeinflusst. Code-Splitting, Lazy Loading und ein kleineres Bundle senken das Risiko.

Wann sollte ich Client-Side Rendering wählen?

Für Tools hinter dem Login, Dashboards und stark interaktive Apps, bei denen die Bildschirme selbst nicht in der Suche auftauchen müssen. Für öffentliche Inhaltsseiten sind Server-Rendering oder statische Generierung eine Überlegung wert.