The Three Ways to Embed a 3D Model on a Product Page (and Which to Pick)

If you sell a premium product on Shopify and you want to put a 3D model on the PDP, there are exactly three architectures to choose from. Each fits a different timeline and a different level of integration with the rest of the page. Picking the wrong one means either shipping fast and rebuilding later, or building slow and shipping nothing. This guide covers the three options and the buyer-flow question that decides between them.

Option 1: web component

Google's is a self-contained web component built on Three.js under the hood. The setup is two files and one custom element:

<script type="module" src="https://ajax.googleapis.com/ajax/libs/model-viewer/4/model-viewer.min.js"></script>

<model-viewer
  src="https://cdn.example.com/product.glb"
  ios-src="https://cdn.example.com/product.usdz"
  poster="https://cdn.example.com/product.webp"
  alt="Product"
  ar
  ar-modes="webxr scene-viewer quick-look"
  camera-controls
  auto-rotate>
</model-viewer>

That ships rotate, zoom, AR placement, a poster fallback, and a default loading state. iOS Quick Look handles the AR step on iOS via the USDZ; Android Scene Viewer handles it on Android via the GLB.

Right for. Stores that want the rotate-and-AR experience and nothing else. Stores with a small product range and a fixed PDP template. Stores where the team does not own a frontend developer who can maintain a Three.js component.

Not right for. Stores where the rest of the page has to know what the buyer did in the viewer. The viewer is a black box from the rest of the page's perspective. Events are limited; reading the camera state from outside the component is awkward.

Time to ship. A weekend for a single product. A week to roll across a Shopify catalog with a theme template change.

Option 2: iframe app

The Shopify-native 3D viewer apps (Arty, LEVAR, Cappasity, Magic 360) all run the same way under the hood: a small script the theme adds, which then injects an iframe pointing at the app's hosted viewer. The model lives in the app's CDN; the page passes a product id and the iframe handles the rest.

Right for. Stores that want a managed solution: someone else handles the viewer code, the AR setup, the analytics. Stores that want to test 3D on one product before committing to a build. Stores with a non-technical merchandiser who needs to upload models without touching the theme.

Not right for. Stores where the viewer has to integrate with the rest of the page. The iframe is a hard boundary. The page cannot read the viewer's state; the viewer cannot read the page's state. Postmessage events bridge some of this but not enough for a deep buyer flow.

Time to ship. Same day for a single product. A week to roll across the catalog.

The honest comparison of 3D viewer apps for premium Shopify stores covers which iframe-based app fits which category.

Option 3: Custom Three.js component

Build the viewer yourself in Three.js, render it inline in the page DOM, and wire it into the rest of the page state. The buyer rotates the watch; the proof block under it updates. The buyer taps a hotspot; the spec section scrolls to the matching row. The buyer scrolls the page; the camera transitions to a new angle.

Right for. Stores at $400+ AOV where the buyer flow is part of the conversion lift, not the rotation alone. Stores that own a frontend developer who can maintain a Three.js component. Stores building a multi-product story flow that goes beyond the rotate-and-AR demo.

Not right for. Stores that need to ship 3D this week. Stores without a frontend developer. Stores where the viewer is the whole feature, not part of a larger story.

Time to ship. 4 to 8 weeks for a production v1. The Three.js production viewer guide covers the four parts most builds skip.

What about hybrid approaches

A few patterns that look hybrid but usually are not worth the complexity:

• with custom Three.js extensions. The web component is sealed; extending it usually means forking it, which is the worst of both worlds.
• Iframe app with deep postmessage integration. Possible, but the messaging API of most iframe apps is thin. By the time you have a working integration, the custom Three.js component would have shipped.
• Multiple viewers on the same PDP. A for the AR step and a Three.js viewer for the in-page rotation. Heavier than picking one. Sometimes worth it for stores migrating between architectures, rarely worth it as a default.

How performance compares

All three architectures fit the same mobile budget if compressed correctly. The runtime cost of the viewer code itself differs:

• : ~250 KB minified after the GLTFLoader and Three.js subset.
• Iframe app: Variable; the iframe itself is cheap, but the app's bundle inside can run from 200 KB to 800 KB depending on features.
• Custom Three.js: Depends on how aggressive your tree-shaking is. 200 to 500 KB is typical.

The bigger budget is always the model and textures. The WebGL product page performance guide covers the asset budget that decides whether the viewer ships under a 2-second LCP.

Where to start

If your store has not shipped 3D at all, start with on the highest-AOV product. Verify the GLB exports cleanly. Verify the AR step works on iOS and Android. Measure conversion against the same product without the viewer for two weeks.

If the conversion lift shows up but the buyer flow feels disconnected from the rest of the page, that is the signal to invest in a custom Three.js component. Plan for 4 to 8 weeks; budget for a frontend developer who knows WebGL.

If you have not started and your store sells $400+ AOV with a story-driven page, skip and go straight to custom Three.js. The integration is the conversion lift, not the rotation.

The buyer is on a phone. The viewer is one of three architectures. The right pick is the one that fits the buyer flow, not the one that fits the timeline.