Server side vs client side rendering: waar kies jij voor?

Men spreekt van SSR wanneer een server een webpagina genereert en deze naar een cliënt stuurt wanneer deze wordt opgevraagd. De bezoeker ontvangt de volledig gerenderde pagina en hoeft alleen nog maar deze te tonen aan de gebruiker. In de context van HTML betekent dit dat de het de server is die de content vertaalt naar HTML-code en deze vervolgens naar de bezoeker verstuurt. De browser kan deze HTML-code vervolgens gemakkelijk vertalen naar de betreffende content. Dit betekent dat de server de meeste van de rendering-werklast draagt, wat betekent dat de apparaat van de gebruiker minder werk hoeft te doen om de pagina te laden en te tonen. Een groot voordeel van server side rendering is dan ook dat men er vrijwel zeker van kan zijn dat de webpagina overal en op welk apparaat dan ook te openen is.

Een nadeel aan SSR is echter dat er vaak onnodig veel rendering-werklast bij de server wordt neergelegd. Neem bijvoorbeeld een blog die je gelezen hebt. Stel dat je de blog hebt gelezen en klikt op een andere blog onder een kopje als ‘recommended for you’, dan zal de server beide webpagina’s gaan renderen, terwijl jij op dat moment alleen interesse hebt in de blog waarnaar je zojuist hebt doorgeklikt. Zeker in periodes waarin er veel verkeer is op de website, kan dit leiden tot lange laadtijden, of zelfs erger.

Men spreekt van CSR, wanneer een server een webpagina stuurt naar een client, maar de client verantwoordelijk is voor het renderen van de pagina. Dit betekent dat de bezoeker de HTML, CSS en JavaScript-bestanden ontvangt en dat zijn/haar browser deze vervolgens moet verwerken tot content. De bezoeker moet zo meer werk moet doen om de pagina te laden en te renderen. Het zal de oplettende lezer vast opvallen dat het genoemde probleem bij SSR zich hier niet voordoet. De server hoeft immers alleen de HTML, CSS en JavaScript-bestanden te versturen naar de gebruiker, waardoor de rendering werklast minder is dan wanneer men gebruik maakt van SSR. Zo zal de laadtijd van de website drastisch afnemen. Bovendien zijn de kosten voor jou als website-eigenaar bij gebruik van CSR lager, aangezien je de server en de daarbij behorende infrastructuur minder gebruikt.

Een nadeel van CSR is echter dat de bezoeker JavaScript-code ontvangt. Dit betekent dat de gebruikte browser deze code wel moet kunnen lezen. Hoewel alle browsers die jij en ik dagelijks gebruiken (of ze nou gedateerd zijn of niet), hier geen probleem mee hebben, is het voor bots minder makkelijk om deze code te verwerken. Als jij dus beoogt dat jouw website zo hoog mogelijk in de zoekresultaten verschijnt en dat de gedeelde links naar jouw webpagina op een moderne manier worden gepresenteerd (met afbeeldingen, titel en paginabeschrijving), is CSR op het eerste oog waarschijnlijk niet de beste oplossing.

Zoals we hebben gezien, kennen beide vormen van rendering hun voor- en nadelen. Dit betekent echter niet dat we door voor de ene vorm te kiezen, automatisch de voordelen van de andere vorm mislopen. Het is namelijk mogelijk deze methoden te combineren en zo een gulden middenweg te bewandelen.

Bij een eerste bezoek aan een website wordt de HTML-code dan op traditionele wijze aan de kant van de server gegenereerd en in deze vorm teruggestuurd naar de gebruiker. Samen met deze code wordt echter ook JavaScript verzonden. Verdere interacties op de webpagina worden uitgevoerd via de geüploade JS-code, hetzelfde als bij rendering aan de clientzijde.

Hierdoor kunnen we de voordelen combineren en de nadelen van beide bovengenoemde oplossingen elimineren. Is het dan de perfecte optie? Helaas niet. De hybride oplossing die we hier voorstellen is veel moeilijker te implementeren, en vereist daarom meer geschoolde medewerkers en kost meer tijd. Dit vertaalt zich dan weer in hogere implementatiekosten. Het kan ondanks deze kosten echter zeker de moeite waard zijn om te kiezen voor de hybride oplossing. Ben jij benieuwd of dit voor jouw webapplicatie opgaat? Onze Drupal experts gaan graag met je in gesprek!

Een ander voordeel van SSR is dat het beter is voor SEO (zoekmachineoptimalisatie). Zoekmachines hebben moeite om de inhoud van dynamische webpagina's te indexeren, omdat deze pagina's worden gegenereerd aan de kant van de gebruiker. Met SSR wordt de volledige webpagina echter gegenereerd op de server, wat betekent dat zoekmachines deze makkelijker kunnen indexeren.

Als jouw focus ligt op SEO, kan het dus zo zijn dat SSR de betere keuze is. Zoekmachines hebben moeite om de inhoud van dynamische webpagina's te indexeren, omdat deze pagina's worden gegenereerd op de client-kant. Met SSR wordt de volledige webpagina echter gegenereerd op de server, wat betekent dat zoekmachines deze makkelijker kunnen indexeren. Dit kan leiden tot een betere positie in de zoekresultaten, wat kan bijdragen aan het verkeer naar de website.

Hoewel SSR op het gebied van SEO vaak als de beste optie wordt beschouwd, zijn er ook andere factoren waar rekening mee moet worden gehouden. Zoals eerder vermeld, kan SSR moeilijker te implementeren zijn en kan het resulteren in langere ontwikkeltijden. Aan de andere kant kan CSR flexibeler zijn en makkelijker te implementeren, vooral voor toepassingen die vaak worden bijgewerkt of die veel gebruikersinteractie hebben.

Als we het besprokene betrekken op het CMS-systeem Drupal, moet bij de keuze voor het gebruik van SSR of CSR gekeken worden naar de specifieke vereisten van de toepassing. Drupal biedt ondersteuning voor beide methoden, dus het is aan jou als ontwikkelaar om te bepalen welke methode het beste past bij jouw behoeften. Afhankelijk van de doelen en vereisten van de te realiseren weboplossing, kan gekozen worden voor CSR, SSR, ofwel een hybride vorm. Onze Drupal experts helpen u uiteraard graag bij het maken van deze keuze.