Spring GDS 25. Jubiläum
Ein Logistikunternehmen, das in 190 Länder versendet, hat etwas gebaut, um an sich selbst zu liefern.
Server-Side Rendering baut das HTML einer Seite auf dem Server, für jede Anfrage, und sendet es fertig an den Browser. Der Nutzer sieht echten Inhalt, sobald er ankommt, noch bevor JavaScript läuft. Danach hydriert die Seite: Das JavaScript koppelt sich an, und das statische Markup wird zu einer lebendigen, interaktiven App.
Das ist das Gegenstück zum Client-Side Rendering, bei dem der Browser eine fast leere Hülle erhält und alles selbst zusammensetzt. SSR gewinnt an zwei Fronten, die zählen: Der erste sichtbare Inhalt erscheint schneller, und Suchmaschinen sowie Link-Vorschauen sehen vollständigen Inhalt statt einer leeren Seite. Der Preis ist Serverarbeit bei jeder Anfrage und der Hydrationsschritt, der träge wirken kann, wenn eine Seite zu viel JavaScript ausliefert. SSR unterscheidet sich auch von der statischen Generierung, bei der Seiten einmal im Voraus gebaut werden. SSR baut pro Anfrage neu, was man für Inhalte will, die sich pro Nutzer oder pro Minute ändern. Ein angemeldetes Dashboard, das Sie mit Namen begrüßt und Ihre letzten Bestellungen zeigt, wird auf dem Server gerendert, damit die Daten im Moment des Ladens stimmen.
Frameworks wie Next.js, Nuxt und Remix machten SSR zum Standard, indem sie eine einzige Codebasis auf dem Server rendern und im Browser laufen lassen, ohne ein separates Backend für die Ansichten.
Der Großteil unserer Webarbeit beruht auf Rendering-Entscheidungen, die wir bewusst treffen, Route für Route. Eine Marketingseite, die ranken muss, wird serverseitig gerendert oder statisch generiert. Ein tief interaktives internes Tool rendert eventuell im Client, wo SEO keine Rolle spielt. Wir entscheiden danach, wofür die Seite da ist, nicht nach einer Framework-Voreinstellung, die jemand stehen ließ. Dieses Urteil ist der Kern unseres Ansatzes in der Webentwicklung.
Die Hydration ist der Punkt, an dem SSR-Projekte still scheitern, also behalten wir sie genau im Blick. Abweichungen zwischen Server- und Client-Ausgabe, überdimensionierte Bundles, die die Interaktivität verzögern, Layoutverschiebungen, die den Core Web Vitals schaden. Unser Performance- und SEO-QA läuft gegen die gerenderte Ausgabe, nicht gegen den lokalen Rechner eines Entwicklers, denn genau das erhalten echte Nutzer und Crawler.
Brauchen Sie Seiten, die schnell laden und ranken? Lassen Sie uns für jede die richtige Rendering-Strategie wählen.
Ein Logistikunternehmen, das in 190 Länder versendet, hat etwas gebaut, um an sich selbst zu liefern.
Eine Marke in ein funktionierendes Geschäft verwandeln.
Eine halbe Million Menschen. Eine App. Null Chaos.















