Realtime rendering in de browser of op de server?

Twee architecturen die allebei realtime heten

De term realtime rendering wordt voor twee fundamenteel verschillende opzetten gebruikt, en dat veroorzaakt bijna alle verwarring in offertes.

Renderen in de browser. Het 3D model wordt naar de bezoeker gestuurd en zijn eigen apparaat berekent elk beeld, meestal via WebGL of WebGPU. Dit is wat de meeste configuratorplatforms doen.

Renderen op een server. Het model blijft op een renderserver. Die berekent het beeld en stuurt alleen het resultaat naar de bezoeker. Het apparaat van de klant toont een afbeelding en rekent niets uit.

Beide zijn realtime in de zin dat de klant direct ziet wat hij kiest. Maar ze leggen tegengestelde beperkingen op.

De afweging

Wat het verschil kost, uit twee offertes voor hetzelfde project

Dit is het deel dat vrijwel nergens staat, en het is contra-intuïtief.

In juni 2026 hebben wij voor één en hetzelfde project twee offertes uitgebracht: dezelfde producten, dezelfde functionaliteit, alleen een andere renderarchitectuur. Daardoor is het verschil zuiver te vergelijken. De klantnaam en de projectkortingen laten we hier weg; het gaat om de verhouding.

Modelwerk voor browser-rendering kostte ongeveer het dubbele, en leverde een lagere beeldkwaliteit op. Dat is het omgekeerde van wat de meeste mensen verwachten, want browser -rendering voelt als de eenvoudige en goedkope route.

De verklaring: een model dat soepel in een browser moet draaien, moet je optimaliseren. Polygonen terugbrengen, materialen vereenvoudigen, texturen comprimeren, en dat alles testen op zwakkere apparaten. Dat is handwerk per model. Bij server-side rendering sla je die hele stap over, omdat de renderserver het model aankan zoals het is.

Wat je bij server-side rendering terugkrijgt aan modelwerk, betaal je in rekencapaciteit per beeld. Dat is een doorlopende kostenpost in plaats van een eenmalige. Bij een groot assortiment kantelt het snel naar server-side, omdat je de optimalisatieslag per model niet hoeft te maken.

Het probleem met vereenvoudigen

Dit is de kern van de zaak en de reden dat wij voor de serverroute kozen.

Een technisch product komt vaak uit CAD met honderdduizenden tot miljoenen polygonen en materiaaleigenschappen die kloppen met de werkelijkheid. Om dat in een browser te draaien op een gemiddelde telefoon, moet het model worden teruggebracht tot een fractie daarvan. Wat sneuvelt zijn precies de dingen waarvoor je 3D wilde inzetten: de naad, de textuur van het materiaal, de manier waarop licht op een gelakt oppervlak valt.

Je zit dan in een tang: hoe breder het apparaatbereik dat je wil bedienen, hoe verder je de kwaliteit moet terugbrengen. Wij nemen die stap niet. Onze configurator rendert op onze eigen servers, waardoor hoge brondata hoge uitvoer blijft en het toestel van de klant niet de limiterende factor is.

Hoe snel is snel genoeg

De relevante vraag bij server-side rendering is de responstijd: hoe lang duurt het voordat de klant het nieuwe beeld ziet nadat hij een keuze maakt.

Op onze eigen productie-configuratoren meten wij, van website tot render, gemiddeld 0,5 seconde. De snelste renders komen rond 0,3 seconde binnen, de langzaamste rond 1 seconde. Die spreiding hangt af van hoeveel er opnieuw berekend moet worden.

Dat gemiddelde is het getal om mee te rekenen, niet het minimum. Een leverancier die een absolute bovengrens belooft, belooft iets wat hij bij een complexe configuratie niet kan waarmaken. Vraag daarom naar het gemiddelde én de uitschieter naar boven.

Ter vergelijking: browser-rendering reageert na het laden vrijwel direct, maar begint met een zware eerste laadtijd waarin het model gedownload moet worden. Je verplaatst de wachttijd van "elke keuze" naar "één keer aan het begin". Welke van de twee erger is, hangt af van hoeveel keuzes een bezoeker gemiddeld maakt.

Wanneer browser-rendering juist beter is

Het is geen eenrichtingsverhaal. Browser-rendering wint op drie punten.

Geen kosten per beeld. De bezoeker levert de rekenkracht. Bij zeer hoge bezoekersaantallen met eenvoudige producten is dat economisch gunstiger.

Geen netwerkafhankelijkheid na het laden. Sleep- en draaibewegingen reageren direct, ook bij een slechte verbinding. Voor vrij ronddraaien met continue beweging voelt dat soepeler.

Eenvoudige geometrie is geen probleem. Een stoel in twaalf kleuren en drie houtsoorten heeft geen zware modellen nodig. Dan is de beperking van WebGL geen echte beperking.

De vuistregel: hoe eenvoudiger je product en hoe belangrijker vrije continue interactie, hoe meer de browser-route opweegt. Hoe complexer je product en hoe belangrijker beeldkwaliteit, hoe sterker de serverroute wordt.

Wat je in een offerte moet vragen

Leveranciers zijn zelden expliciet over welke architectuur ze gebruiken. Drie vragen maken het duidelijk:

1. Wordt het beeld berekend op het apparaat van mijn klant of op jullie servers?
2. Als het in de browser gebeurt: tot hoeveel polygonen wordt mijn model teruggebracht, en op welk toestel is dat getest?
3. Wat gebeurt er op een vijf jaar oude telefoon?

Op die derde vraag krijg je het eerlijkste antwoord. Browser-rendering laat oudere toestellen zichtbaar afvallen, en in een consumentenmarkt is dat een substantieel deel van je bezoekers.

Waarom dit een verkoopvraag is, geen technische

Het lijkt een keuze voor de ontwikkelaar, maar het bepaalt wat je klant ziet op het moment dat hij beslist. Een vereenvoudigd model dat er plastic uitziet, verkoopt een premium product niet. Omgekeerd: een configurator die op een oud toestel niet laadt, verkoopt helemaal niets.

Kies daarom vanuit je markt. Verkoop je op kwaliteit en detail, dan is de kwaliteitsgrens van je architectuur je verkoopgrens.