Commerce·May 2024·9 min read

Integrating AR/VR into E-Commerce Platforms for Immersive Shopping

Product AR shipped. The metaverse showroom and the glasses-free hologram did not. What works today is a dual-format 3D asset — glTF for everyone, USDZ for iOS — wired into a product page through the <model-viewer> web component or a native AR handoff, no headset required.

What "AR/VR integration" actually means now

Two other posts on this site already covered the wreckage: what the metaverse storefront pitch promised and what actually shipped, and what glasses-free holographic display is and isn't ready for retail. Both land on the same three real technologies: glTF-based 3D viewers, WebXR-driven AR, and native AR handoffs on iOS and Android.

This post is the how. Not the market analysis, the build: what file formats you need, which web component or native API renders them, and where the integration actually breaks in production.

There is no VR storefront layer worth wiring up in 2026. Nobody is putting on a headset to browse a product catalog. What is real, and normal now, is phone-based AR: point the camera at a room, drop a 1:1 scale 3D model of the product into it.

The three real delivery paths

The <model-viewer> web component: a Google-maintained custom element that renders a glTF/GLB model in-page and hands off to native AR on supported devices (modelviewer.dev docs). This is the path most product teams should start with.
Native AR handoff: iOS routes to AR Quick Look with a USDZ file (Apple — AR Quick Look); Android routes to Google's Scene Viewer with a glTF/GLB file (Google — model-viewer AR). <model-viewer> triggers both automatically based on the visiting device.
Raw WebXR Device API: the lower-level browser API for building a custom in-page AR session instead of handing off to a native viewer (W3C — WebXR Augmented Reality Module). Only worth the extra engineering if you need interaction the standard place-and-view flow doesn't support, and only Chromium-based browsers on Android implement it in a shipping state.

The dual-asset pipeline: one product, two file formats

Every AR-ready product needs two exports, not one. glTF (usually as its binary form, GLB) is the Khronos Group's open standard for 3D scenes and is what <model-viewer>, Android Scene Viewer, and most commerce platforms consume directly (Khronos — glTF).

iOS needs USDZ, Apple and Pixar's zipped USD container built specifically for AR Quick Look (OpenUSD — release documentation). <model-viewer> can generate a USDZ on the fly from your GLB if you don't supply one, but a purpose-built export renders more predictably, especially for materials with reflectivity or transparency.

Format	Consumed by	Notes
GLB (binary glTF)	<model-viewer>, Android Scene Viewer, Shopify's web 3D viewer	Open standard; export from Blender, a CAD pipeline, or a photogrammetry tool
USDZ	iOS AR Quick Look only	Apple/Pixar format; <model-viewer> can auto-generate one, but a dedicated export handles materials more reliably
Neither (raw WebXR session)	Custom in-page AR built directly against the WebXR Device API	No file handoff at all — the model is loaded and rendered inside your own WebGL scene, so you own the entire rendering pipeline

Shopify's Storefront API models this exactly as two files on one product: a Model3d media object that serves the GLB to the web viewer and the USDZ to iOS visitors from the same product record (Shopify — Model3d object). If you're not on a platform that handles this natively, that's still the pattern to copy: one product, two files, device-based selection at render time, not two separate product pages.

Wiring it into a product page

A working integration is a handful of attributes on one element:

<model-viewer
  src="chair.glb"
  ios-src="chair.usdz"
  ar
  ar-modes="webxr scene-viewer quick-look"
  camera-controls
  poster="chair-poster.webp"
  loading="lazy"
  reveal="interaction"
  alt="Walnut dining chair, 3D model">
</model-viewer>

ar-modes is ordered by preference — list webxr first if you want in-browser AR tried before the native handoff, since not every device supports it.
poster shows a static image until a visitor interacts, so the page doesn't pay the full model download cost on first paint.
loading="lazy" defers fetching the model entirely until the viewer scrolls into view, the same discipline you'd apply to an image below the fold.
reveal="interaction" holds the model back until a visitor actively engages, instead of loading it the moment it's in the viewport.
camera-controls gives non-AR visitors (most desktop traffic) a rotate-and-zoom fallback instead of a dead viewport, and it's keyboard-operable by default once an element has focus, which matters for the accessibility review this component will eventually get.

Two more attributes worth setting deliberately: ar-scale="fixed" locks the model at real-world scale in AR and disables pinch-resizing, which matters for anything sold by exact dimension — furniture, appliances, wall art. Wire the component's own ar-status and ar-tracking events into your analytics so an AR session that never actually starts (camera permission denied, unsupported device) doesn't get silently counted as one that did.

Ship the poster image and defer the GLB/USDZ download until a visitor actually engages with the viewer. A 3D model is a large, render-blocking-adjacent asset — treat it like a video embed, not an <img>.

Optimizing the asset, not just the markup

An unoptimized GLB export from most 3D tools is heavier than it needs to be: unnecessary vertex data, uncompressed textures, animation tracks nobody uses on a static product view.

Compress the mesh with Draco, Google's open-source geometry compression library, supported natively by <model-viewer> and most modern glTF viewers (GitHub — google/draco).
Run the export through glTF-Transform to strip unused nodes, resize textures, and re-pack materials before it ever reaches production (GitHub — glTF-Transform).
Cap texture resolution deliberately. A product photographed for a 4K hero shot does not need 4K textures on a model most visitors will view at phone-screen size.
Serve models from a CDN with long cache lifetimes. A GLB or USDZ doesn't change unless the product does, so cache it as aggressively as you'd cache a versioned image asset.

None of this is optional for a catalog of any size. A merchandising team exporting a fresh GLB per SKU without a compression step in the pipeline will eventually ship a 40MB model on a product page and wonder why mobile conversion dropped.

Failure modes that eat a launch

Browser and OS support is not uniform

WebXR is unsupported in desktop and mobile Safari and unimplemented in Firefox; it works in Chromium browsers on Android and, partially, visionOS Safari for VR sessions specifically (MDN — WebXR Device API). That's exactly why the native-handoff path (Quick Look, Scene Viewer) exists: it's the fallback that actually reaches iPhone users, who make up a large share of any US commerce site's mobile traffic.

Lighting and material mismatch

A model lit and textured for a studio render often looks wrong dropped into a dim living room via AR. Metallic and glass materials are the worst offenders — they pick up environment lighting in AR in a way a fixed studio render never has to account for. Test the actual AR placement, not just the in-page 3D preview, before calling an asset done.

QA burden scales with catalog size

Every SKU with an AR-ready model is a new asset to version, re-export when the product photography changes, and re-test across at least two native viewers. Budget for this as an ongoing content operation, not a one-time build. A team that treats 3D assets as a launch deliverable instead of a maintained content type ends up with stale models next to updated product photography within a year.

Scale accuracy is the actual product promise

AR Quick Look and Scene Viewer both place the model at real-world scale by default, which means an export with the wrong unit system or a missing scale reference ships a chair that's visibly the wrong size in someone's living room. Verify real-world scale against a known dimension before an asset goes live, not after a return comes back citing "looked bigger online."

Whether it's worth it for a given catalog

There is no public, citable benchmark for AR's effect on conversion or return rate that applies to your catalog — the physical scale, material accuracy needs, and price point of what you sell all change the answer. Treat this as a measurement problem, not an assumption.

Pick a category where scale or material genuinely drives purchase hesitation: furniture, wall art, anything sized for a specific space.
Ship AR on that category only, behind a flag or a percentage rollout.
Compare add-to-cart rate and post-purchase return rate against a held-out control group on the same category.
Only then decide whether the asset-production cost is worth extending catalog-wide.

Categories where AR rarely earns its production cost: anything already sold primarily on price, anything with negligible size or material ambiguity, and anything where the shopper already owns a comparable physical reference (most apparel, most consumables). Spend the asset budget where the camera actually resolves genuine purchase hesitation.

A rollout checklist

Export GLB and USDZ from the same source model for every SKU in scope.
Run every GLB through Draco compression and glTF-Transform cleanup before it reaches storage.
Wire <model-viewer> with ar, an explicit ar-modes order, a poster image, loading="lazy", and camera-controls.
Verify real-world scale against a known physical dimension before publishing.
Test the actual AR placement on a physical iPhone and a physical Android device, not just a simulator.
Instrument add-to-cart and return rate on the AR-enabled category before deciding to scale it up.

FAQ

Do I need WebXR if I already have <model-viewer>?

No. <model-viewer> already includes webxr as one of its ar-modes options and handles the handoff for you. Reach for the raw WebXR API only when you need an in-page AR experience the standard place-and-view flow doesn't cover.

Can I skip the USDZ export and let <model-viewer> auto-generate it?

Yes, functionally. But an auto-generated USDZ can render materials less accurately than a dedicated export, so treat it as a fallback for long-tail SKUs, not the default for hero products.

Does this work without a native app?

Yes. AR Quick Look and Scene Viewer are OS-level features triggered from a browser link — no app install required for the shopper.

What about VR headsets?

Not worth building for commerce today. Headset-based shopping never reached meaningful retail traffic; see the metaverse post-mortem linked above for why.

How big should a product GLB be?

There's no official universal limit, but the direction is unambiguous: compress the mesh, cap texture resolution, and treat every megabyte as a mobile-conversion cost, not a rounding error.

Is <model-viewer> accessible out of the box?

Its camera controls are keyboard-operable and it accepts a standard alt attribute, but the AR trigger itself still needs a visible, labeled button in your own markup — don't rely on an unlabeled icon as the only way to launch it.

References

From the Destm engineering archive. For current work on this topic, start at Solutions or the blog.