De pagina die niemand zag over rendering, React en de keuzes die ertoe doen

Stel je voor: je hebt weken gewerkt aan een mooie webapplicatie. De componenten zijn netjes opgezet, de data komt binnen, en het voelt goed. Je stuurt de link door naar een collega. Die opent hem op zijn laptop, wacht even... en ziet een wit scherm. Een seconde later laadt alles in, maar die ene seconde was al genoeg om de indruk te verpesten.

Wat er achter de schermen gebeurt op het moment dat iemand een URL opent, bepaalt veel meer dan je zou denken. Het bepaalt hoe snel je pagina zichtbaar is, of Google hem kan lezen, en hoe zwaar de belasting op jouw server of de browser van de gebruiker valt. En precies daar zit het verschil tussen Client Side Rendering en Server Side Rendering.

Eerst de browser, dan de inhoud dat is CSR

Bij Client Side Rendering stuurt de server een vrijwel lege HTML-pagina naar de browser. Daarin staat eigenlijk weinig meer dan een <div id="root"></div> en een verwijzing naar een JavaScript-bundel. De browser downloadt die bundel, voert hem uit, en pas dan wordt de pagina opgebouwd.

React werd groot met deze aanpak. Je schrijft componenten, React injecteert ze in de DOM, en de gebruiker ziet een dynamische, snappy applicatie zodra alles geladen is.

Dat "zodra" is precies de adder onder het gras. Op een snelle laptop met glasvezel valt het nauwelijks op. Op een middelmatig Android-toestel op 4G kan het voelen als wachten op een trage lift. De Time to First Contentful Paint het moment waarop de gebruiker écht iets ziet hangt volledig af van hoe snel de JavaScript gedownload en uitgevoerd is.

Er is nog een tweede probleem: zoekmachines. Traditionele webcrawlers indexeren HTML. Als die HTML leeg is totdat JavaScript alles opbouwt, loop je het risico dat je pagina slecht of helemaal niet geïndexeerd wordt. Voor een interne dashboard-applicatie is dat geen issue. Voor een publieke productpagina kan het je SEO flink schaden.

Eerst de inhoud, dan de browser dat is SSR

Bij Server Side Rendering draait de logica niet in de browser, maar op de server. Wanneer een gebruiker een pagina opvraagt, bouwt de server de volledige HTML op inclusief alle data en content en stuurt dat kant-en-klare document naar de browser.

De gebruiker ziet meteen iets. De crawler van Google ook. Pas daarna laadt het JavaScript in de achtergrond, en neemt React de controle over om de pagina interactief te maken. Dit proces heet hydration: de statische HTML wordt als het ware tot leven gewekt.

Het resultaat is een beduidend betere First Contentful Paint en een sterk verbeterde SEO-positie maar het heeft een prijs. De server moet nu werk doen bij elke request. Bij een druk bezochte site kan dat leiden tot hogere serverlasten en latency, zeker als je data per gebruiker verschilt en je niet slim omgaat met caching.

Next.js: het beste van beide werelden

Hier komt Next.js in beeld. Next.js is een framework bovenop React dat je de keuze geeft niet als een globale instelling, maar per pagina, per component.

Je kunt een marketingpagina volledig server-side renderen voor optimale SEO. Een dashboard kun je client-side laten werken voor maximale interactiviteit. En voor pagina's met content die zelden verandert zoals een blogpost of een productcatalogus biedt Next.js nog een derde optie: Static Site Generation (SSG), waarbij de HTML al wordt gegenereerd tijdens het bouwen van de applicatie en niet pas bij elke request.

Vanaf Next.js 13 is daar de App Router bijgekomen, met React Server Components als fundament. Hiermee worden componenten standaard op de server gerenderd, tenzij je ze expliciet als client component markeert met "use client". Dit verschuift het denken van "hoe render ik mijn pagina?" naar "welke componenten hebben écht toegang tot de browser nodig?"

Wanneer kies je wat?

De eerlijke boodschap is: er is geen universeel juist antwoord. De keuze hangt af van wat je bouwt en voor wie.

Een interne tool voor een klein team dat toch al ingelogd is, waar SEO geen rol speelt en snelle interactiviteit voorop staat? Dan is een pure CSR-aanpak met React prima. Een publieke website met veel content, waar vindbaarheid en laadsnelheid cruciaal zijn? Dan wil je SSR of SSG, en is Next.js een logische keuze.

En in de meeste moderne projecten zul je allebei nodig hebben. Dat is precies waarom Next.js zo populair is geworden niet omdat het één aanpak oplegt, maar omdat het je dwingt bewust na te denken over waar je logica thuishoort.

Het witte scherm dat niemand wil zien is vermijdbaar. De vraag is alleen: ben je bereid de juiste keuze te maken vóórdat je begint te bouwen?