Real-time rendering in the browser or on the server?

Two architectures that are both called real time

The term real-time rendering is used for two fundamentally different set-ups, and that causes almost all the confusion in quotations.

Rendering in the browser. The 3D model is sent to the visitor and their own device calculates every image, usually through WebGL or WebGPU. This is what most configurator platforms do.

Rendering on a server. The model stays on a render server. That calculates the image and sends only the result to the visitor. The customer's device displays a picture and calculates nothing.

Both are real time in the sense that the customer sees straight away what they choose. But they impose opposite limitations.

The trade-off

What the difference costs, from two quotations for the same project

This is the part that is written down almost nowhere, and it is counter-intuitive.

In June 2026 THE REAL MAG. issued two quotations for one and the same project, the same products, the same functionality, only a different rendering architecture. That makes the difference a clean comparison. We leave out the client name and the project discounts here; what matters is the ratio.

Modelling work for browser rendering cost roughly twice as much, and delivered lower image quality. That is the opposite of what most people expect, because browser rendering feels like the simple and cheap route.

The explanation is simple. A model that has to run smoothly in a browser has to be optimised. Reducing polygons, simplifying materials, compressing textures, and testing all of it on weaker devices. That is manual work per model. With server-side rendering you skip that whole step, because the render server handles the model as it is.

What you get back in modelling work with server-side rendering, you pay in computing capacity per image. That is an ongoing cost rather than a one-off one. With a large range it tips quickly towards server-side, because you do not have to make the optimisation pass for every model.

The problem with simplifying

This is the heart of the matter and the reason THE REAL MAG. chose the server route.

A technical product often comes out of CAD with hundreds of thousands to millions of polygons and material properties that match reality. To run that in a browser on an average phone, the model has to be reduced to a fraction of it. What gets lost is exactly the things you wanted to use 3D for, the seam, the texture of the material, the way light falls on a lacquered surface.

You are then caught in a vice. The wider the device reach you want to serve, the further you have to reduce the quality. THE REAL MAG. does not take that step. Our configurator renders on our own servers, so high-grade source data stays high-grade output and the customer's device is not the limiting factor.

How fast is fast enough

The relevant question with server-side rendering is the response time. How long it takes before the customer sees the new image after making a choice.

On the production configurators of THE REAL MAG. we measure, from website to render, 0.5 seconds on average. The fastest renders come in around 0.3 seconds, the slowest around 1 second. That spread depends on how much has to be recalculated.

That average is the figure to work with, not the minimum. A supplier who promises an absolute ceiling is promising something they cannot deliver on a complex configuration. So ask for the average and the outlier at the top end.

For comparison. Browser rendering responds almost immediately once loaded, but starts with a heavy first load in which the model has to be downloaded. You move the waiting from "every choice" to "once at the start". Which of the two is worse depends on how many choices a visitor makes on average.

When browser rendering is the better choice

It is not a one-way story. Browser rendering wins on three points.

No cost per image. The visitor supplies the computing power. With very high visitor numbers and simple products that is economically better.

No network dependence once loaded. Dragging and rotating respond immediately, even on a poor connection. For free rotation with continuous movement that feels smoother.

Simple geometry is no problem. A chair in twelve colours and three woods does not need heavy models. In that case the limitation of WebGL is not a real limitation.

As a rule of thumb, the simpler your product and the more important free continuous interaction is, the more the browser route weighs up. The more complex your product and the more important image quality is, the stronger the server route gets.

What to ask for in a quotation

Suppliers are rarely explicit about which architecture they use. Three questions make it clear.

1. Is the image calculated on my customer's device or on your servers?
2. If it happens in the browser, down to how many polygons is my model reduced, and on which device was that tested?
3. What happens on a five year old phone?

That third question gets you the most honest answer. Browser rendering makes older devices drop out visibly, and in a consumer market that is a substantial share of your visitors.

Why this is a sales question, not a technical one

It looks like a choice for the developer, but it determines what your customer sees at the moment they decide. A simplified model that looks like plastic does not sell a premium product. And the other way round. A configurator that does not load on an old device sells nothing at all.

So choose from your market. If you sell on quality and detail, the quality ceiling of your architecture is your sales ceiling.