WebXR product experiences that load in a browser

By Marco Lopes · August 21, 2024 · Design, 3D & XR

A product page can describe an object, photograph it, and show it in motion. Sometimes, though, we need to turn it around ourselves. We want to inspect a connector, understand how a mechanism opens, or see whether a piece of equipment fits the space where we intend to use it.

At Kordspace, we approach browser-based 3D and WebXR as product design tools, not novelty layers. As a remote collaborative software, AI, Web3, hardware, and design studio, we connect visual work with the engineering needed to make it useful.

The goal is straightforward: let people explore a product from a link, with as little friction as possible. Achieving that takes more than exporting a model and adding an AR button.

Start with the decision, not the technology

Before we choose a renderer or build a scene, we identify the decision the experience should support. Is someone comparing finishes, checking dimensions, learning a maintenance procedure, or deciding whether to request a quote?

Each goal implies a different interaction. A finish selector needs consistent materials and lighting. A training experience needs clear sequencing. A placement tool needs trustworthy scale and an explanation of tracking limitations.

We turn that goal into a small, testable journey: open the page, inspect the relevant detail, perform one useful action, and continue toward the next step.

If a photograph or short video answers the question better, we use that instead. Browser-based 3D earns its place when interaction reveals something that static media cannot communicate as effectively.

Separate browser 3D from immersive WebXR

An interactive 3D viewer is not automatically a WebXR experience. We can render a product inside a normal web page using WebGL without entering an immersive session.

WebXR adds browser APIs for supported augmented and virtual reality experiences, including device poses, input, and session management. Its availability depends on the browser, operating system, hardware, and requested capabilities.

As of August 2024, we should not assume that a mobile browser supports immersive WebXR simply because it displays 3D. In particular, we cannot plan around general immersive WebXR availability in Safari on iPhone and iPad.

We therefore design several paths: an ordinary product page, an interactive browser viewer, and an immersive option where supported. Platform viewers such as Apple Quick Look or Android Scene Viewer can provide additional AR routes, but these are handoffs rather than the same in-page WebXR implementation.

Design the fallback as part of the product

We build the essential product information in HTML first. The name, specifications, price where relevant, and primary action should remain usable if the model fails to load or the device cannot start an immersive session.

A useful progression is a poster image, followed by an interactive viewer, followed by an optional AR or VR mode. We explain what each button does rather than expecting people to understand labels such as “XR.”

“View in your space” is clearer for placement. “Explore in 3D” makes sense for a turntable viewer.

We also provide a way back. Closing the viewer should preserve the selected configuration and return people to a sensible place on the page. An unsupported capability should never become a dead end between someone and the product information they came for.

Build assets for delivery, not just presentation

A model that looks excellent in a desktop rendering package may be unsuitable for the web. CAD exports can contain excessive geometry, hidden internal parts, tiny fasteners, and materials that do not transfer cleanly.

We create a delivery asset deliberately. That includes removing invisible surfaces, simplifying geometry where the silhouette allows it, checking normals, and reducing unnecessary material slots.

For browser delivery, glTF or GLB is usually a practical starting point. We evaluate geometry compression such as Draco or Meshopt and texture compression through KTX2/Basis Universal, confirming support in the chosen viewer pipeline.

Compression is not free: smaller downloads can introduce decoding work. We test both transfer size and startup cost.

We also verify units, orientation, origin, and bounding boxes. A polished model with incorrect scale can make an AR placement experience actively misleading.

Set a performance budget before adding detail

We agree on representative devices and network conditions early. Testing only on a recent development laptop hides the constraints that shape the actual experience.

Our budget covers model and texture downloads, decoder costs, JavaScript, GPU memory, draw calls, and time until someone can interact. There is no single file-size target that fits every product; we choose one according to the audience and validate it on devices.

We load the poster and essential page content first, then defer heavier assets until they are likely to be useful. We avoid downloading every finish variation up front when materials or textures can be requested on demand.

Lighting deserves scrutiny too. A restrained environment map and baked detail can communicate a product more reliably than expensive real-time shadows. We optimize for sustained usability, not a beautiful first frame followed by overheating.

Choose the smallest stack that meets the need

For a straightforward product viewer, we often evaluate <model-viewer>. It provides a useful foundation for displaying models, managing camera interaction, and offering supported AR paths without building every interaction from scratch.

When the experience requires custom assemblies, complex annotations, simulation, or specialized rendering, Three.js or Babylon.js can offer more control. In a React application, React Three Fiber may help integrate scene development with the surrounding interface.

We choose based on behavior, team skills, and maintenance needs rather than the longest feature list.

The trade-off is ownership. A custom scene means we own camera limits, picking, loading states, memory cleanup, touch behavior, and accessibility integration. We prototype the riskiest requirement first so that an attractive framework choice does not conceal a fundamental platform limitation.

Make interaction understandable on the first attempt

We start with a useful camera angle and a visible product. People should not need to discover the object by dragging an empty scene.

Rotation, zoom, part selection, and configuration need clear boundaries. On mobile, a viewer must coexist with page scrolling rather than capturing every touch unexpectedly. We use concise hints and remove them once they have served their purpose.

Annotations work best when they answer specific questions. A hotspot explaining a removable filter is more valuable than a cluster of decorative labels.

We keep important controls in accessible HTML wherever possible, with keyboard support, visible focus states, and meaningful labels. We offer text equivalents for essential visual information, respect reduced-motion preferences, and avoid forced auto-rotation. Accessibility is part of the interaction model, not a caption added after rendering is finished.

Treat AR placement as a guided workflow

An AR placement flow needs more than permission handling. We explain how to find a suitable surface, show when tracking is ready, and provide an obvious placement confirmation.

Where WebXR hit testing is available, we can use it to help position the object on detected surfaces. We request only the features the workflow actually needs and provide recovery instructions when tracking becomes unreliable.

We preserve real-world scale when size matters. If resizing is allowed, we make that state explicit and offer a reset to the product’s actual dimensions.

We also avoid presenting visual placement as a precision measurement tool. Lighting, tracking, surface detection, and device capabilities affect the result. For clearance-sensitive installations, we show the official dimensions and direct people to verify them independently.

Keep configuration state outside the scene

A configurable product needs a reliable source of truth. We model selections as application data and let the scene reflect that state, rather than burying business rules inside mesh names or click handlers.

This helps us keep the viewer, specification summary, pricing logic, and next-step action aligned. If a finish is unavailable for a particular component, the interface should explain the constraint before showing an impossible combination.

We can also serialize permitted selections into a shareable URL so colleagues or customers reopen the same configuration. We validate that data rather than trusting query parameters.

For remote collaboration, we review versioned assets against shared acceptance criteria: geometry, materials, dimensions, interaction, and performance. Clear ownership between design and engineering prevents late discoveries that a visually approved model cannot ship efficiently.

Deploy assets like a production application

Google Cloud is our preferred starting point when the project fits. A practical setup can use Cloud Storage for static models and textures, with an external Application Load Balancer and Cloud CDN for delivery. Cloud Run can serve configuration APIs or other application services.

We configure HTTPS, correct content types, cross-origin access where needed, and deliberate cache policies. WebXR requires a secure context, so deployment configuration is part of functionality, not just operations.

We use content-hashed filenames for long-lived asset caching and keep a manifest that identifies the current release. This makes rollbacks and cache behavior easier to reason about.

AWS or Azure can support equivalent patterns when they better match an existing environment. We keep the asset pipeline portable rather than coupling every model export to one provider.

Test failure paths and measure useful outcomes

We test real devices across the agreed browser matrix, including unsupported browsers. We cover slow connections, interrupted downloads, denied permissions, orientation changes, lost tracking, and repeated entry into and exit from immersive modes.

Automated tests can check asset availability, configuration logic, and interface behavior. They do not replace hands-on testing of camera movement, placement, visual quality, or thermal performance.

For analytics, we define meaningful events: viewer ready, load failure, configuration completed, placement started, and the relevant next-step action. An AR button click alone does not tell us whether the experience helped.

We avoid collecting camera imagery or detailed spatial data by default. Any collection of sensitive information needs a clear purpose, appropriate consent, and a retention policy. We can learn a great deal from ordinary interaction and reliability metrics.

A short pre-launch checklist

Before release, we confirm that:

• The experience answers a specific product question.
• Essential information works without 3D or immersive support.
• Models have verified scale, orientation, materials, and licensing.
• Loading and interaction meet the agreed device budget.
• Controls support keyboard use and understandable recovery states.
• AR handoffs, permissions, and unsupported devices are tested.
• Asset caching, rollback, analytics, and privacy settings are reviewed.

We prefer a focused first release that performs reliably over an ambitious scene that only works during a demonstration. From there, we can improve detail and interaction using evidence from actual use.

The best browser-based product experiences make complex objects easier to understand without making the surrounding journey harder. If we can help turn your product into a useful, accessible 3D or WebXR experience, start a project with Kordspace, or explore our related services pages to see how we bring design, software, and hardware work together.