English
繁體中文
A configurator goes live, the product team celebrates, and three weeks later someone in sales mentions that customers keep saying the page "hangs". Nothing is broken, exactly. Which is the hard part, because a web 3d configurator performance problem rarely throws an error. It just quietly loses people on mid-range phones while the studio's desktop looks fine.
Most of what's written about this assumes you are building from scratch. This is for the other situation: the thing already exists, and you need to know where the weight is. Six checks, in the order that finds the biggest problems fastest. None of them needs a new tool beyond the browser you already have.
What the audit is measuring
Three numbers decide whether a configurator feels instant or feels broken, and they are not the same number.
Download size of the default view is the blunt one: everything a shopper must fetch before the model can be touched. Alongside it sits LCP ownership, because if the canvas owns Largest Contentful Paint, the 3D is now responsible for your Core Web Vitals score whether you intended that or not. And then there is time to first interaction, the moment a drag actually rotates something, which is the number your customers experience as speed. A configurator can pass one and fail the other two, which is why "it loads in two seconds" claims from vendors are worth very little without knowing what counted as loaded.
Check one: the weight of the default view
The measurement takes a private window, an honest throttle setting such as Fast 3G, and the network panel watched while the configurator pulls its first files. Not the total after five minutes of browsing, the initial payload.
Numbers to hold in mind. A CAD export converted straight to glTF routinely lands between 40 and 120 MB per variant, which is a white screen on a phone for twenty seconds or more; Draco or meshopt typically brings the same asset into single-digit megabytes. Studios targeting fast storefronts publish initial payload goals around 2 MB, loading optional detail afterwards. If the default view pulls 15 MB before the shopper touches anything, nothing else on this list matters yet, and 3d configurator loading speed becomes a modeling problem rather than a front-end one.
The rest of that check is whether the configurator belongs on the page at all. Configurator scripts belong only on pages that use them, and the model should arrive after a trigger, a "view in 3D" tap or the section entering the viewport, not on page load. Google indexes HTML, and a canvas full of geometry contributes nothing to that, so the text content needs to render first and fast.
Where the canvas steals the score
What appears on screen first tells you most of the story. If it is a spinner inside an empty frame, the page has taken a hit it did not need to take, because a poster image plus a fixed aspect ratio would have held the space and earned a decent paint time. Layout shift counts here too: a 3D container that resizes once the model arrives pushes content around and shows up in the field data as instability.
Who gets blamed for LCP is the next thing to establish. In a setup built in the wrong order, the canvas claims it, and every subsequent optimization of the 3D is now optimization of a metric that would have been fine with a static image. The fix is architectural rather than cosmetic, and it is the reason experienced teams insist the product title, price and buy button are ordinary HTML that paints before the viewer initialises.
Mobile reality
Your audience is not the studio's phone. One practitioner publishing nine real deployments puts mobile at roughly 70% of configurator traffic, which matches what we see; customers browse on a couch, or on site, not at a desk.
Two specifics worth checking. Device pixel ratio is the first: rendering at 3x on a retina phone multiplies GPU work for a difference almost nobody perceives, and clamping it to 2 recovers a large share of the cost. Repeated geometry is the second: a configuration with forty identical slats, all separate meshes, will crawl, while instanced rendering draws them in one call. If frame rate collapses when an option multiplies identical parts, the problem is draw calls rather than file size.
Shader compilation deserves a mention too, because it is invisible on a fast laptop. On mid-range Android, the first render can stall while shaders compile, and a progressive loader that shows a low-detail version first hides that stall behind something useful.
The hidden multiplier: textures per variant
Textures are usually the biggest share of the download, and they multiply silently. A PBR set for one fabric often means three or four maps, and if each fabric carries its own full set loaded upfront, adding options adds megabytes. Check whether the browser is fetching maps for fabrics the shopper never selected.
Two changes fix most of it. Textures go to 2K at most for product viewing, 1K for small items, and they are served in a format the GPU can use directly rather than one that must be fully decompressed first, which is what KTX2 with Basis Universal is for. The other change is on-demand fetching: load the default configuration, fetch a fabric when it is chosen, preload the likely next choice in the background. Perceived speed improves more from this than from any compression ratio.
There is a ceiling to what front-end work can recover, too. Once the geometry itself is heavier than the product needs, every fix downstream is a compression of waste, and the practical alternative is rebuilding the asset. The techniques for that belong to the asset pipeline rather than the page, and reduce GLB file size for web walks through them in the order that pays off.
Geometry and texture work like this belongs upstream, in how models are prepared before they ever reach the store, which is the discipline covered in preparing CAD files for a web 3D configurator.
What to fix in what order
Nothing here is exotic, but the order matters, because fixing textures on a model nobody should have uploaded wastes the effort.
Trim the default payload first, both what loads and whether it loads at all. Defer the viewer until intent, serve a poster, reserve the space. Then attack textures, since they usually hold the most weight: cap resolution, use GPU-friendly formats, stop shipping every variant's maps. Geometry compression and instancing come next, and the exact codec matters less than testing decode time on a real mid-range device, with the decoder self-hosted rather than pulled from a third-party CDN that adds hundreds of milliseconds before anything appears.
How much of this the shopper sees also depends on how the viewer is presented, which format carries the interaction, and whether a static alternative exists for the devices that cannot manage the runtime; the trade-offs are outlined in interactive 3D product display.
One of these checks we run on every project before launch, and it has never come back empty: open the page on the cheapest phone in the office and time it with a stopwatch. If the first interaction takes longer than a breath, the numbers above will tell you why. When a build is already live and nobody can say where the weight sits, tell us about the setup and we will run the audit with your team. A web 3d configurator performance problem is almost always found in an afternoon and fixed in a fortnight, once somebody knows where to look.
FAQ
Q: What counts as a good load time for a web 3D configurator?
Measure the default view rather than the full experience. A payload around 2 MB and a first interaction within one to two seconds on a mid-range phone is a sensible target; anything above 10 MB before interaction tends to show up in abandonment on mobile networks.
Q: Will compressing models fix a slow configurator?
Partly. Compression reduces download, but if the viewer still loads on page load, ships every variant's textures, and renders at 3x pixel ratio, the page stays slow. Deferral and texture strategy usually deliver more than codec choice.
Q: How do I know whether the canvas is hurting Core Web Vitals?
Check which element owns LCP in PageSpeed Insights or the performance panel. If it is the 3D canvas, the viewer is on the critical path and needs to move behind a poster image and a trigger. If LCP is the product title or hero image, the 3D is not your bottleneck.
