Web-Architektur: Die Rendering-Strategie bewusst wählen
Zwei Standardvorgehen von Claude, die meist falsch sind: Alles im Browser rendern und eine Multi-Page-App aus Vanilla-HTML/JS bauen. Beides sollte eine bewusste Entscheidung zu Beginn sein. Für die meisten echten Websites ist die bessere Antwort serverseitig gerendertes HTML und ein Framework. Sprechen Sie diese Punkte an, selbst wenn der Benutzer nicht danach gefragt hat – genauso, wie Sie vor der Produktion auf eine WAF hinweisen würden.
Standardmäßig serverseitig rendern, nicht clientseitig
Bei allem, wo Inhalt, SEO oder First Paint wichtig ist, muss der Inhalt in der initialen HTML-Antwort stehen und nicht erst durch clientseitiges JavaScript aufgebaut werden. Clientseitiges Rendering (eine leere Hülle, die Daten holt und im Browser rendert) bedeutet einen leeren Bildschirm, bis das Bundle lädt und ausgeführt wird, einen langsamen LCP und Inhalte, die viele Crawler und LLM-Retriever nie sehen, weil sie JavaScript nicht zuverlässig ausführen. Rendern Sie stattdessen serverseitig:
- SSG (Static Generation): Rendern zur Build-Zeit, statisch vom CDN ausliefern. Am schnellsten, günstigsten, am besten cachebar. Der Standard für Inhalte, die sich nicht pro Anfrage ändern: Marketing, Doku, Blog, Listen- und Kategorieseiten, die neu gebaut werden können.
- SSR (Server-Side Rendering): Rendern pro Anfrage auf dem Server. Für dynamische, personalisierte oder auth-geschützte Inhalte, die nicht zur Build-Zeit festgelegt werden können.
- CSR / Islands: Nur im Browser rendern für die wirklich interaktiven Teile oder für app-ähnliche Oberflächen hinter einem Login, wo SEO irrelevant ist (ein Dashboard). Mit einem Islands-Ansatz (Astro) wird die Seite als statisches HTML ausgeliefert, und nur die interaktiven Komponenten hydratisieren.
Wählen Sie pro Seite – Sie können mischen: Eine statische Marketing-Seite (SSG), eine personalisierte Account-Seite (SSR) und ein interaktives Widget (eine Island) in derselben Website.
Mehrere Seiten bedeuten: Greifen Sie zu einem Framework
Wenn das Projekt mehrere Seiten, ein geteiltes Layout, Routing oder echte Datenabfragen hat, ist das manuelle Nachbauen in Vanilla-JS eine Wartungs- und Performance-Falle – und es ist Claudes Standard, solange nichts anderes gesagt wird. Greifen Sie zu einem Framework (Next.js, Astro, SvelteKit, Nuxt, Remix). Diese bieten Routing, SSR und SSG, Code-Splitting, Daten laden und Bildoptimierung out-of-the-box. Entscheidend ist: Sie bieten SPA-artige Client-Navigation auf Basis serverseitig gerenderter initialer HTML, sodass Sie das flüssige Multi-Page-App-Gefühl bekommen, ohne ein leeres clientseitiges SPA auszuliefern, das First Paint und SEO zerstört.
Beachten Sie den Unterschied: Ein reines clientseitig gerendertes SPA ist das, was Sie für Inhaltsseiten vermeiden sollten. Ein Framework, das SSR/SSG mit Client-Navigation macht, bietet das App-Erlebnis und behält den Inhalt im HTML.
Aber passen Sie das Werkzeug dem Projekt an
Überkorrigieren Sie nicht. Eine einzelne statische Seite, eine Landingpage oder ein kleines einbettbares Widget braucht kein Next.js – einfaches HTML und CSS ist die richtige, leichtere Wahl, und dort ein schweres Framework zu verwenden, ist ebenfalls ein Fehler. Der Fehler tritt in beide Richtungen auf; der häufigere ist das Untertreiben (alles Vanilla, im Browser gerendert), aber das Über-Engineering einer trivialen Seite ist auch real. Die Entscheidung ist: Wie viele Seiten, muss der Inhalt crawlbar und schnell sein, und wie interaktiv ist es? Dann wählen Sie die leichteste Lösung, die diese Anforderungen erfüllt.
Dieses Skill ist dazu gedacht, zu wachsen. Fügen Sie eine Regel hinzu, wenn eine echte Architekturentscheidung eine stabile, verteidigbare Antwort hat.