SSR wieder vorne – warum?
Vor ein paar Jahren noch: Jeder zweite Pitch drehte sich um React, Vue & Co. Hauptsache, alles im Browser. 2026 ist die Laune anders. Viele Projekte gehen zurück zu serverseitigem Rendering. Warum? Weniger Ballast, weniger Bugs, weniger Kopfweh mit SEO.
Die Praxis: Zu viele SPAs sind lahm beim ersten Laden. Google meckert, Kunden klicken weg. Dann noch die Pflege – jeden Monat ein Framework-Update, irgendwas bricht immer. Für die meisten Sites einfach zu viel Theater. Nicht jede Bäckerei will ein Frontend-Framework warten.
Wann ist SSR einfach die bessere Idee?
Typisch: Seiten, die sich selten ändern, aber bei Google auftauchen sollen. Oder wo der Inhalt wichtiger ist als Animationen. Wer auf Mobilgeräte zielt oder im Funkloch hängt, ist mit klassischem HTML schneller dabei.
- Firmen-Homepages
- Nachrichtenportale
- Blog mit übersichtlichem Autorenkreis
Beispiel: Lokale Handwerksseite, Relaunch 2025. Vorher SPA – Ladezeit 3,7 Sekunden, SEO im Keller. Nach Umstieg auf SSR: unter 1 Sekunde, Anrufe nehmen zu. Support fragt, warum es plötzlich weniger Ticket-Anfragen gibt.
SPAs? Sind noch da – aber gezielter
Niemand hat die SPA beerdigt. Wer Live-Daten, viele Formulare oder Dashboards braucht, bleibt beim Client. Aber: 2026 ist der Mix Standard. Erstmal HTML ausliefern, dann per JS nachladen, was gebraucht wird. Next.js, Nuxt – kennen alle, nutzen viele, aber nicht immer freiwillig.
- Chat-Apps (echt jetzt, wer will da jedes Mal reloaden?)
- Interaktive Formulare (Steuererklärung, anyone?)
- Echtzeit-Dashboards (Monitoring, Börse, etc.)
Aber: Das Setup wird schwerer, die Wartung aufwendiger. Wer’s nicht wirklich braucht, ärgert sich später über kaputte Builds oder Hosting-Kosten.
Agentur und Hosting: Was zählt wirklich?
30 Jahre Webentwicklung, gefühlt 1000 Projekte gesehen: Am besten laufen die Sachen, die simpel bleiben. SPA-Pflege frisst Zeit ohne Ende. Kleine Teams stolpern über Mini-Details – plötzlich ist das Hosting zu schwach, oder ein Update killt die Build-Chain. PHP 8.3 auf Shared Hosting? Läuft. Node.js? Meistens – bis der Provider umstellt.
Kunden merken schnell, wenn’s hakt. SPAs werden nach Relaunch oft wieder auf SSR zurückgebaut. Der Wartungsaufwand nervt, Performance ist mies, SEO wird zur Dauerbaustelle. Wer klassisch bleibt, hat weniger böse Überraschungen.
2026: Was läuft stabil, was ist Bastelbude?
- PHP oder Node.js SSR: Stabil, wartbar, auch 2026 kein Hexenwerk. Wer SEO und Performance will, nimmt das. Siehe Back to Basics: Klassische PHP-Architektur 2026 – oft der pragmatischere Weg oder … weniger Framework, mehr Übersicht.
- Hybrid-Ansätze (Next.js/Nuxt): Nett, aber kein Wundermittel. Aufwand? Nicht unterschätzen.
- Deno Desktop: Für richtig dynamische Apps, auch als Node-Alternative. Mehr dazu: Deno Desktop 2026: Wirklich ein Ersatz für Node.js?
Meine Einschätzung nach fast 30 Jahren Webentwicklung
SPA lohnt sich nur, wenn’s wirklich interaktiv werden soll. Für fast alles andere reicht SSR locker. Agenturen mit fünf bis zehn Leuten sparen sich mit SSR jede Menge Frust: weniger Frontend-Bastelei, weniger Hosting- und Sicherheitsärger, weniger Panik vor Google-Updates. Fokus bleibt auf Inhalt statt auf Framework-Gymnastik.
Allein-Admins mit WordPress? Die lachen über SPA-Probleme. Schnell, wartbar, fertig. Einziger Nachteil: Wer zu viel JS nachrüstet, flucht irgendwann über die PageSpeed-Tools.
Kurz: 2026 lieber einfach
SSR ist wieder Standard – aus gutem Grund. Performance, Wartung, Übersicht: alles besser, wenn’s nicht zu komplex wird. Wer wirklich eine SPA braucht, weiß das vorher. Also: Erst fragen, was das Projekt wirklich können muss. Nicht jeder Webauftritt braucht eine Sledgehammer-Lösung.
Mehr dazu? Siehe Back to Basics: Warum 2026 klassische PHP-Architektur in vielen Webprojekten wieder vorne liegt.
bye
mo