A 3D product viewer for e-commerce can arrive as a reusable web component, a hosted service or a product your team builds and operates. Those labels describe procurement only loosely. The useful distinction is who owns the runtime, asset pipeline, storefront integration, acceptance testing, support and exit path after launch.
Choose an embed or library when the shopping task is mostly standard inspection and your team can own frontend delivery. Choose a managed viewer when operational capacity, onboarding and a contracted service matter more than unrestricted control. Fund a custom build when the interaction itself is differentiated and the business is prepared to maintain it. None is the universal best choice.
The file format does not settle that decision. Khronos describes glTF as a royalty-free runtime-delivery specification, and a scene can be stored in one binary .glb file.[1] A GLB can therefore move through all three models. What changes is the operating system around it.
This page owns that buyer decision. For the broader responsibilities of formats, UX, performance and analytics, use the 3D Product Viewer Guide. For detailed loading, fallback and page-performance implementation, continue to How to Make a 3D Product Page Load Fast Without Sacrificing UX.
Compare operating models before products
The terms "build" and "buy" hide hybrids. A custom experience may still use open-source libraries. A managed service may ship through an embed. The following Double Edged framework classifies the model by primary operating responsibility, not by the JavaScript found in the page.
| Operating model | What you take on | What you can contract or reuse | Strong fit signal | Warning signal |
|---|---|---|---|---|
| Embed or library | Storefront code, deployment, asset hosting or routing, analytics, compatibility QA and incident response | A component or engine, documented controls and release updates | Standard rotate, zoom, hotspots or reveal behavior fits the buying task, and a capable web team already owns the product page | The team treats a code snippet as a finished service and leaves no owner for assets, updates or browser failures |
| Managed viewer or SaaS | Product truth, source assets, catalog mapping, commerce integration, approval and vendor governance | Hosted runtime, delivery infrastructure, administration, onboarding or support, as the contract states | The team needs a repeatable operating path and values service capacity more than deep runtime control | Required behavior, data access, export rights or support terms remain outside the signed scope |
| Custom build | Product definition, viewer application, deployment, observability, security, compatibility, support and roadmap | Engines, standards, cloud services and specialist delivery partners | Viewer behavior carries differentiated product rules, guided selling or integration that generic controls cannot express cleanly | The business funds launch features but not ownership after launch |
Do not score a candidate until each row has a named internal owner. "The vendor handles it" is not an answer unless the service description, limit and escalation route are written into the contract.
Understand what each path really buys
Embed or library: buy a capability, operate the experience
A web component can shorten the path to a conventional viewer. The official <model-viewer> project, for example, exposes a custom element for interactive 3D and documents current browser support.[2] Its loading examples cover posters, manual reveal, GLB and glTF inputs, plus optional decoder configuration.[3] That is useful leverage, but it does not approve the product model, choose the product-page placement, map variants, configure analytics or respond to a failed release.
Library ownership also includes dependency policy. The three.js installation guide supports npm with a build tool or CDN imports, calls for consistent versions and treats controls and GLTFLoader as separate addons.[4] If the team selects this model, name who reviews releases, locks versions, tests upgrades and can roll back.
This path is not automatically the cheapest. It removes some implementation work while keeping most commerce and operational work with you. It is attractive when requirements stay close to supported controls and the existing web team wants control of hosting, styling and measurement.
Managed viewer or SaaS: contract an operating boundary
A managed viewer can combine software delivery with asset preparation, hosting, administration and support. The exact combination is contractual, not implied by the word "managed." Ask which team owns model correction, material review, variant mapping, theme work, analytics access, consent, uptime communication and end-of-term exports.
A commerce platform's native media path is a useful reminder. Shopify documents that its hosted 3D models use Google's model-viewer component, while each theme still needs a responsive media approach and must preserve interaction inside surrounding carousels or swipe displays.[6] Managed infrastructure does not erase storefront responsibility.
This model fits when the buyer values a defined service and predictable publishing workflow. It becomes risky when the demonstration is mistaken for the contract, or when the team cannot retrieve assets, mappings, analytics and implementation knowledge if the relationship ends.
Custom build: own differentiation and its maintenance
A custom build is justified by behavior, not by the desire to own more code. Product-rule visualization, unusual comparison modes, guided assembly, specialist data integration or a tightly coupled buying flow may warrant a dedicated application. Custom does not mean writing a rendering engine from scratch; it can use glTF and maintained libraries while the team owns the product logic and release system.
That control has a maintenance cost. Three.js documents that applications must explicitly dispose of unused textures, geometries and materials because those resources are not released automatically during a running page.[5] Resource lifecycle is one small example of work that a custom owner must design, test and monitor rather than assume away.
Write the ownership ledger first
Use this original ownership table during discovery. Replace every "shared" cell with two named parties and a handoff rule before signing.
| Responsibility | Embed or library | Managed viewer or SaaS | Custom build | Acceptance evidence |
|---|---|---|---|---|
| Product geometry, scale and materials | Buyer or asset partner | Buyer plus any contracted preparation team | Buyer or build team | Approved product reference and signed asset review |
| Viewer runtime and releases | Buyer web team | Provider within contract | Buyer build team | Version record, release notes and rollback test |
| Hosting, delivery and decoder dependencies | Buyer | Provider or shared | Buyer | Architecture record and failure test |
| Product-page and variant integration | Buyer | Shared | Buyer | Representative SKU and variant reconciliation |
| Accessibility and non-3D fallback | Buyer | Shared, unless explicitly contracted | Buyer | Task-based keyboard, pointer and fallback review |
| Analytics, consent and data access | Buyer | Shared | Buyer | Event dictionary, consent test and raw-data access check |
| Browser and device regression | Buyer | Shared support matrix | Buyer | Dated matrix with exact devices, browsers and results |
| Incidents and shopper support | Buyer | Shared escalation | Buyer | Severity definitions, contact route and response rehearsal |
| Asset updates and catalog operations | Buyer | Shared workflow | Buyer | Update test with roles, timing and approval evidence |
| Exit, export and replacement | Buyer | Provider obligations plus buyer migration | Buyer | Export sample, deletion terms and replacement drill |
The table exposes gaps earlier than a feature comparison. If both parties think the other owns accessibility or variant mapping, the operating model is already incomplete.
Calculate TCO without inventing a price
A free library, a subscription and a custom project produce costs in different places. Compare them over one declared horizon, catalog scope and traffic assumption. Use the same currency, tax treatment, regions, asset count, variant count, expected viewer sessions and support hours. Do not place an undisclosed "custom estimate" beside a public subscription and call the totals comparable.
Original TCO equation
TCO = implementation + asset preparation + platform or licence + hosting and transfer + integration maintenance + compatibility QA + content operations + support and incidents + exit or migration - internal work genuinely avoided
| Cost bucket | Embed or library question | Managed viewer or SaaS question | Custom-build question |
|---|---|---|---|
| Initial implementation | Who integrates, styles, instruments and secures it? | What setup and commerce work is excluded? | Which discovery, design, engineering and launch work is funded? |
| Asset readiness | Who optimizes, reviews and republishes each model? | What preparation volume and revision depth are included? | Does the build include an asset pipeline or only a viewer? |
| Recurring runtime | What hosting, CDN, monitoring and dependency costs remain? | Which usage, storage, region, support or overage terms apply? | What infrastructure and observability scale with use? |
| Change | Who handles browser, theme, analytics and catalog changes? | Which changes are configuration, paid service or unavailable? | What team capacity maintains product logic and dependencies? |
| Failure | What is the cost of diagnosis and rollback? | What support level, evidence and remedy does the contract provide? | Who is on call, and how is the application restored? |
| Exit | Can another implementation reuse the GLB files, mappings and event history? | Which assets, metadata and logs can be exported, in what form and when? | Is documentation sufficient for a new team to operate the system? |
Run low, expected and high usage cases without fabricating vendor rates. The purpose is to reveal cost sensitivity. A managed path may trade internal staffing for contracted fees. A custom path may front-load engineering but still incur ongoing operation. An embed may have no licence fee and still require substantial labor. The model with the lowest quote can have the least complete boundary.
Put failure and exit risk beside the TCO
Cost without risk rewards missing scope. Add probability and impact only after the team defines a scale; otherwise labels such as "high" look precise while meaning different things to each reviewer.
| Risk | Early evidence to request | Control | Accountable owner |
|---|---|---|---|
| Asset renders incorrectly in the target viewer | Normal SKU and risk-case GLB compared with approved product evidence | Asset acceptance gate and viewer-specific regression set | Product and 3D leads |
| Initial page or opened viewer misses its budget | Cold and warm measurements with exact file, device, browser and network profile | Poster or intent-based loading, asset budget and measured release gate | Web performance owner |
| Interaction excludes shoppers | Keyboard review, single-pointer alternative and non-3D fallback | Accessible controls and an equivalent product-information path | Product and accessibility owners |
| Variant mapping drifts from commerce data | Reconciliation across representative option changes | Stable IDs, mapping validation and rollback | Commerce integration owner |
| Dependency or provider change breaks the release | Upgrade trial or provider change notice tested in staging | Version policy, regression suite and rollback route | Runtime owner |
| Exit package cannot recreate the experience | Sample export and replacement walkthrough before commitment | Contracted export format, documentation and deletion evidence | Commercial and technical owners |
For drag-operated functions, WCAG 2.2 Success Criterion 2.5.7 requires a single-pointer alternative unless dragging is essential or controlled by the user agent.[8] A rotate interaction should therefore be evaluated as a shopper task, not accepted because a mouse drag worked in a demo.
Run one controlled evaluation before selection
This article reports no viewer benchmark. No candidate build, release-candidate GLB, browser/device inventory or network profile was supplied, so publishing pass times or file-size limits would create false evidence. Use one normal SKU and one known risk case, then record the following test contract before any trial.
| Test | Tested file | Browser and device | Network assumptions | Acceptance threshold |
|---|---|---|---|---|
| Initial product page | Exact page build plus immutable GLB filename, byte size and checksum, even if loading is deferred | Exact device model, operating system and browser version for every supported class | Cold cache and warm repeat; record downlink, uplink, latency and packet-loss profile | Named page budget and no regression beyond the pre-viewer baseline |
| Viewer launch | The same immutable release candidate | The same declared matrix, with automation separated from real-device checks | Cold asset and warm asset runs recorded separately | Click-to-first-usable-view time, failure rate and fallback timing agreed before testing |
| Visual and product acceptance | Normal and risk-case GLBs tied to approved geometry, scale and material evidence | Every launch viewer and representative display class | Stable connection so network failure does not mask visual review | Zero unresolved product-identity defects; every permitted visual variance documented |
| Interaction and accessibility | Same files and control configuration | Keyboard, touch and pointer paths on named devices and browsers | Both loaded state and delayed-load state | Every required task works through the declared input alternatives; fallback retains purchase-critical information |
| Repeated use and cleanup | Same files across a declared open, switch and close cycle count | Exact browser/device with memory tooling recorded | Warm cache after the first cycle | No crash, no broken subsequent model and no retained-resource growth beyond the team's stated tolerance |
| Failure and recovery | Corrupt, missing or blocked test asset kept outside production | Same support matrix | Offline, timeout and denied-request cases defined explicitly | Fallback appears within the agreed time, product details remain usable and an observable error reaches the owner |
Page-level performance should be read alongside field data, not replaced by a clean lab run. Google's current "good" Core Web Vitals thresholds are LCP at or below 2.5 seconds, INP at or below 200 milliseconds and CLS at or below 0.1, evaluated at the 75th percentile.[7] Record whether a result is lab or field evidence and segment the viewer-opened journey from the initial page.
The evaluation should end with an operations rehearsal: publish a new asset, change a variant, roll back a bad release, retrieve analytics, open a support incident and produce an exit package. A candidate that only succeeds in the sales demonstration has not passed the operating test.
Inspect the GLB before destination testing
The Private GLB Readiness Checker inspects and previews a selected self-contained GLB locally in the browser, and the selected GLB remains local.[10] It reports exactly four separate destinations: Online store, Shopify, Product customizer and Android AR. A successful browser preview does not prove destination compatibility or performance. The optional editable Excel QA workbook is a secondary resource for team handoff. The checker reports no fifth destination or alternate-format outcome.
Use the result to identify questions for the candidate viewer, then test the finished integration on the declared devices and connections. Local inspection is evidence about the selected file in that browser session, not approval of the eventual commerce experience.
Use proof at the right scale
Spellexo is selective proof that Double Edged has operated a hosted 3D-commerce product with managed asset preparation, click-to-load entry, viewer delivery and ongoing catalog work.[9] Its case study explicitly separates live capability from commerce lift. It does not prove that its model, or any managed model, is right for every catalog.
The final recommendation should fit on one page: buying task, chosen operating model, named owners, evaluated files, test matrix, TCO horizon, top risks, contract exceptions and exit evidence. If the interaction is standard and the web team is capable, start with the narrowest reusable component that passes. If the operational gap is larger than the feature gap, evaluate a managed service. If differentiated behavior earns a durable roadmap, scope a custom product and fund its operation.
For a discussion that starts with the product decision rather than a preset stack, explore interactive 3D product experiences. Bring the ownership ledger and controlled evaluation results; they make a far better brief than a vendor feature checklist.
