Next.js SSR vs SSG vs ISR: wann welcher Modus passt
Next.js SSR vs SSG vs ISR: wann welcher Modus passt - praktischer MillionsCode-Leitfaden mit Kernkriterien, Checkliste, Tools und FAQ.
Next.js SSR vs SSG vs ISR: wann welcher Modus passt
Decision rule
SSR erzeugt HTML bei jeder Anfrage. Das passt zu Dashboards, Bestellstatus, Berechtigungen, privaten Preisen und Seiten, die von Cookies abhaengen.
SSG erzeugt HTML waehrend des Builds. Es passt zu stabilen oeffentlichen Seiten, Dokumentation, Hilfeseiten, Richtlinien und langlebigen Tutorials.
ISR kombiniert statische Geschwindigkeit mit spaeterer Regeneration. Es ist stark fuer Blogs, Produktseiten, oeffentliche Rankings und Vergleichsartikel.
Die Kernfrage lautet Cachebarkeit. Wenn dasselbe HTML vielen Besuchern gezeigt werden darf, sind SSG oder ISR meist besser. Wenn nicht, ist SSR sinnvoll.
Useful internal references: Next.js metadata, PageSpeed checker, meta tag checker, reading time calculator, image format guide.
Practical selection table
| Situation | Prefer | Reason |
|---|---|---|
| Stable public page | SSG | fastest delivery and simple cache |
| Public content with occasional updates | ISR | static speed plus controlled refresh |
| User-specific page | SSR | request data and permissions matter |
| Real-time widget | SSR or client fetch | freshness matters more than build speed |
Operating checklist
Check whether the HTML can be cached, how often the source data changes, whether build time grows with content count, and whether SEO metadata is available in the first response. Also check images, fonts and third-party scripts because they can damage performance even when the rendering mode is correct.
FAQ
Ist SSR immer besser fuer SEO?
Nein. SSG und ISR liefern ebenfalls vollstaendiges HTML und oft schnellere Antworten.
Was passt fuer Blogs?
SSG fuer wenige stabile Artikel; ISR fuer viele Seiten oder regelmaessige Updates.