Server-side rendering (SSR) betekent dat de server de volledige HTML van een pagina opbouwt voordat hij bij de browser aankomt. De bezoeker krijgt bij het eerste antwoord al een afgewerkte pagina, in plaats van een leeg omhulsel dat JavaScript daarna nog moet vullen. Dit is de oude, oorspronkelijke manier waarop het web werkte, en het blijft een sterke keuze voor content die meteen zichtbaar en vindbaar moet zijn.
Denk aan twee restaurants. Het ene serveert je maaltijd volledig opgemaakt (dat is SSR), het andere geeft je de rauwe ingrediënten en een recept om aan tafel zelf te koken (dat is client-side rendering). De opgemaakte maaltijd komt klaar binnen. Daarom voegt een single-page application vaak SSR toe om trage eerste laadtijden en zwakke SEO op te lossen. Het verschil met static generation is dat de server bij elk verzoek werk doet, wat iets meer rekenkracht kost.
SSR komt het best tot zijn recht als een pagina verse, gepersonaliseerde of vaak wisselende data moet tonen en tegelijk snel moet laden en goed moet scoren. Een ingelogd dashboard is het klassieke geval: de inhoud verschilt per gebruiker en verandert per minuut, dus het vooraf één keer opbouwen is geen optie.
Er zit een subtiele addertje onder het gras. De pagina ziet er klaar uit, maar is pas echt bruikbaar als de JavaScript geladen is en het overneemt. Is die code zwaar, dan ziet een bezoeker een knop en klikt erop voordat die echt reageert, dus een lichtere bundel blijft tellen, ook met SSR. Dat is een reden waarom servercomponenten populair werden, want die beperken hoeveel code er überhaupt verstuurd moet worden.
Bij TopDevs kiezen we SSR als een klant zowel snelheid als actuele content nodig heeft, zoals een dashboard of een productcatalogus die de hele dag verandert.
