How do you build a Babylon.js 3D product configurator that loads quickly and passes the configuration to the cart?

Sources checked on 13 November 2026.

This guide is for the person planning a 3D product configurator in an online store or on a manufacturer's website who wants to understand what the 3D layer consists of before commissioning a project. It covers model preparation, performance, browsers and the connection to the cart.

The short version: the quality of a configurator depends on the models and how they are prepared, not on the engine alone. Babylon.js provides a glTF loader, material variant support and scene optimisation tools, but configuration rules and prices have to live outside the scene, in the system that handles the order.

A configurator is more than a rotating model. Before an estimate is made, split responsibility between the parts:

This split lets you change models without touching pricing rules and the other way round. When rules are written only in the scene code, every change to the offer needs a 3D developer's work.

CAD files describe a product for manufacturing, with a precision and level of detail a browser does not need. For a configurator, the model has to be simplified and exported to a format meant for display.

That format is glTF 2.0, described in the Khronos glTF 2.0 specification. A file contains geometry, materials based on a physically based rendering model (PBR), textures and an element hierarchy, and the binary GLB version packs this into one file.

When preparing models, agree with the 3D artist on: the names of elements the configurator will swap or hide, the origin point and scale (glTF uses metres), and a file size budget for the mobile version.

If a product has a dozen colours or finishes, a separate file for each variant lengthens loading on every change.

The KHR_materials_variants extension lets you store many material variants for the same geometry in one glTF file and switch them at runtime without reloading the model. The specification names digital commerce as a typical use, for example switching the colour of a pair of sneakers. The extension is ratified by the Khronos Group. The specification notes that the extension is meant for a finite list of premade variants, not for configurators with dynamic product-building rules.

The Babylon.js glTF loader includes an implementation of this extension (the KHR_materials_variants extension source in the Babylon.js repository), so the variant names stored in the file can match the options in the configurator interface.

On a phone, every megabyte of model lengthens the time to the first image. glTF has extensions that reduce data size:

• KHR_draco_mesh_compression: geometry compression with the Draco library.
• EXT_meshopt_compression: geometry compression with the Meshopt method.
• KHR_texture_basisu: KTX2 textures with Basis Universal compression, which take less space to download and in GPU memory.

According to the Babylon.js glTF loader documentation, for such files the engine by default downloads decoders from the Babylon CDN and runs them in web workers. The documentation notes this can raise data protection (GDPR) concerns or Content Security Policy violations, and recommends hosting the decoders on your own server.

Compression moves some work to the device, which has to unpack the data. Check the choice of method on target phones, measuring the time from opening the page to showing the model.

Babylon.js renders through WebGL or WebGPU. According to the Babylon.js WebGPU documentation, support for this API has been available since version 5.0 in May 2022 and is backward compatible with the WebGL implementation. The difference in application code is that engine initialisation is asynchronous.

According to the MDN page on the WebGPU API, the API is not Baseline because it does not work in some widely used browsers, and it is available only in secure contexts (HTTPS).

For a store configurator, this means WebGL should remain the path that works for every customer. WebGPU can be enabled where the browser supports it, after checking that it makes a measurable difference for your scene.

Configurator performance has two sides: the smoothness of the scene itself and how fast the product page loads. For the scene, the Babylon.js documentation on scene optimisation describes these techniques, among others:

• Instances: repeated elements drawn with a single draw call.
• Freezing materials and world matrices: fewer recalculations for elements that do not change.
• Freezing the active mesh list: saving CPU time when the scene is static.

For the page, what matters is what the customer sees before the scene loads. According to the description of the LCP metric on web.dev, a good result is 2.5 seconds or less, and the list of elements considered covers images, video, background images and text blocks; the list does not include the canvas element. A static product image shown immediately, with the 3D scene loading after it, helps keep that result.

Test on lower-end phones, not only on the team's computers. Set a budget: maximum model size, number of draw calls and time to first interaction.

The configuration chosen in the scene has to reach the cart as data the store, the ERP and production can understand. Agree the format before building the scene:

If the configurator handles products with technical rules, option-dependent prices and quote approval, the 3D layer is only one part of a CPQ system. We describe the rules, prices and ERP connection in our guide to CPQ for manufacturers and B2B ecommerce.

1. A configuration ID stored on the server, not only in the page URL.
2. The list of selected options with codes the ERP or production system knows.
3. A price calculated on the server using the same rules as the cart.
4. An image of the configuration for the cart, order confirmation and quote.
5. The model and rules version, so the configuration can be reproduced after the offer changes.

A configurator cannot be estimated reliably without knowing the product and the state of the models. The scope depends on the number of products and options, the state of CAD files or 3D models, the number of rules excluding options, how the price is calculated and integrations with the store and ERP.

For the first conversation, prepare one product with its full option list, the available model files, a description of how quotes are produced today and a list of devices your customers use to browse the offer.

A sensible first step is a configurator for one product with real data and load time measured on phones. Only then is it worth scaling it to the whole catalogue.