SSR, oftewel server-side rendering, betekent dat de server de complete HTML van een pagina opbouwt elke keer dat iemand hem opvraagt. In plaats van een bijna lege schil te sturen die de browser nog moet vullen, haalt de server de data op, bouwt de pagina en stuurt iets terug dat de bezoeker meteen kan lezen.
Vergelijk het met een gerecht dat vers wordt klaargemaakt versus eentje uit de koelkast. Een kant-en-klaar gerecht (een statische pagina) is meteen klaar maar voor iedereen hetzelfde. Een gerecht op bestelling (een SSR-pagina) duurt een tel langer, maar past precies bij wat jij vroeg. Daardoor past SSR goed bij content die afhangt van wie er is ingelogd, of bij data die continu verandert.
Het belangrijkste nadeel is kosten en snelheid per bezoek. Omdat de server bij elk verzoek werk doet, kan het trager zijn dan een afgerond bestand uit een statische site teruggeven, en je Time to First Byte vraagt om aandacht. Met caching en alleen de dynamische stukken renderen blijft het vlot. Nadat de HTML binnen is, gaat de pagina vaak nog door hydratatie om interactief te worden.
Het helpt om het af te zetten tegen een single-page application, die een lege schil stuurt en alles in de browser bouwt. Voor een app achter een login werkt dat prima, maar een zoekmachine of een trage telefoon ziet niets tot het script draait. Frameworks als Next.js en Astro mengen tegenwoordig allebei: render de eerste weergave op de server en laat de browser het daarna overnemen. Je kiest SSR dus zelden voor de hele site, maar per pagina waar de data vers of persoonlijk is.
Bij TopDevs pakken we SSR erbij als een pagina persoonlijke of realtime data moet tonen, en cachen we stevig zodat bezoekers alsnog een snelle eerste weergave krijgen.
